字符集和校對
客戶端和服務器設置要要保持一致。
校對規則主要是mysql用來比較字符串，比如按照大小寫敏感，或者是二進制。 分別對應了cs,ci(不敏感),bin三個對應項
可以指定校對規則對字段排序，但是這樣可能會不使用原來的索引。
分佈式事務
XA事務需要一個事務協調器來保證所有的事務參與者都完成了準備工作(第一階段)。 都準備好，則提交所有事務(第二階段). Mysql不能扮演這個協調者，只能是參與節點。
內部XA
平衡多個存儲引擎， 以及存儲引擎和寫二進制日誌之間。
如果打開了寫二進制日誌那麼對應的還有這部分XA的消耗。可以使用innodb_support_ca設置爲0，但是這樣又回導致複製不可用。 複製需要二進制日誌和XA實物的支持。
外部XA
也就是一種分佈式同步數據的方法。 因爲網絡延遲，一人等待變成多人等待等等開銷。分佈式XA的代價表達。 可以使用別的方式來實現這種同步，比如本地寫入數據，並且放入隊列，更小的進行增量同步，或者使用Mysql本身的複製機制。
查詢緩存
可以緩存執行計劃，省去解析和生成執行計劃的過程
可以緩存數據，只有sql完全匹配纔會命中緩存
只要相關的表發生了變化，緩存即刻失效
緩存很多時候會成爲資源競爭點，所以都是關閉狀態的，也可以設置的比較小。
Mysql 如何判斷緩存命中
直接使用客戶端發送過來的參數做hash，然後從引用表中查，如何的不同，包括空格等等都會無法命中。
包含不確定因素的函數，比如now()，這種是不會把結果放入緩存的。
緩存可能帶來查詢的提升，但是因爲在查詢前先查緩存，查詢後插入緩存，這樣會是的一些操作的性能下降，並且因爲對於緩存的操作都是加鎖排他的使得效率更低。
特別是當事務中需改了某個表，這是會設置爲該表部分的緩存失效，這個時候如果有該表的查詢操作則會等待，這有可能會造成短暫僵死。
讓緩存發揮最大作用
按照剛纔說的，貌似用緩存有很多的副作用。爲了讓其發揮更好的作用，需要一些原則和技巧。
使用 SQL_CACHE能夠使用緩存， 使用SQL_NO_CACHE 強制不用緩存。
一般對複雜查詢，但是返回信息很少的這種數據用緩存比較合適。
再有一個評價緩存好壞的是緩存命中率
一些配置項：
- query_cache_type OFF,ON,DEMAND(只有明確寫SQL_CACHE的語句纔會放入查詢緩存)
- query_cache_size 總內存空間
- query_cache_limit 能緩存的最大查詢結果。
Mysql緩存替代方案， 可以使用系統內部的緩存而不使用Mysql的緩存。