CPU親和性：
選擇最大性能模式， 避免節能模式導致性能不足
關閉NUMA， 降低swap概率
選擇FORCE WB讀寫策略
選擇合適的充放電策略
高IO， 推薦RAID10
空間需求大則RAID5
vm.swappiness=0
記憶體最大性能模式
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_io_capacity = 3000（PCIE卡建議更高）
innodb_flush_neighbors=0
InnoDB存儲引擎在刷新一個髒頁時， 會檢測該頁所在區(extent)的所有頁， 如果是髒頁， 那麼一起刷新。 這樣做的好處是通過AIO可以將多個IO寫操作合併為一個IO操作。 對於傳統機械硬碟建議使用， 而對於固態硬碟可以關閉
innodb_flush_log_at_trx_commit
redo 的刷盤策略
sync_binlog
binlog 的刷盤策略
innodb_log_buffer_size
建議8-16M， 有高TPS（比如大於6k）的可以提高到32M， 系統tps越高設置可以設置的越大
策略：
系統資源：
併發控制：
最左首碼原則：MySQL會一直向右匹配直到遇到範圍查詢(>、3 and d=4 如果建立(a,b,c,d)順序的索引，
避免重複索引：idx_abc多列索引,相當於創建了(a)單列索引， (a,b)組合索引以及(a,b,c)組合索引。 不在索引列使用函數 如 max(id)> 10 ,id+1>3 等
儘量選擇區分度高的列作為首碼索引：區分度的公式是count(distinct col)/count(*)， 表示欄位不重複的比例， 比例越大我們掃描的記錄數越少
不使用存儲過程、觸發器， 自訂函數
不使用全文索引
不使用分區表
針對OTLP業務儘量避免使用多表join和子查詢
不使用*,SELECT使用具體的列名：在發生列的增/刪時， 發生列名修改時， 最大限度避免程式邏輯中沒有修改導致的BUG， IN的元素個數300-500
避免使用大事務， 使用短小的事務：減少鎖等待和競爭
禁止使用%首碼模糊查詢 where like ‘%xxx’
禁止使用子查詢， 遇到使用子查詢的情況， 儘量使用join代替
遇到分頁查詢， 使用延遲關聯解決：分頁如果有大offset， 可以先取Id， 然後用主鍵id關聯表會提高效率
禁止併發執行count(*)， 併發導致CPU飆高
禁止使⽤order by rand()
不使用負向查詢， 如 not in/like， 使用in反向代替
不要一次更新大量（大於30000條）資料， 批量更新/刪除
SQL中使用到OR的改寫為用 IN() （or的效率沒有in的效率高）
單實例無法解決空間和性能需求時考慮拆分
垂直拆分
水準拆分
引入緩存系統
IO相關的優化可能還不完整， 以後會逐步完善。
關於資料庫系統水準和垂直拆分是一個比較大的命題， 這裡略過， 每個公司的業務規模不一樣， 選取的拆分策略也有所不同。
一、簡介最近在壓測新的存儲，1、具有1-5工作經驗的， 面對目前流行的技術不知從何下手， 需要突破技術瓶頸的可以加群。 2、在公司待久了， 過得很安逸， 但跳槽時面試碰壁。 需要在短時間內進修、跳槽拿高薪的可以加群。 3、如果沒有工作經驗， 但基礎非常扎實， 對java工作機制， 常用設計思想， 常用java開發框架掌握熟練的， 可以加群。 4、覺得自己很牛B， 一般需求都能搞定。 但是所學的知識點沒有系統化，