字段選取：進行節衣縮食，選取最合適的字段屬性
索引相關：怎麼建立索引？聯合索引和覆蓋索引？儘量減少回表次數
資料頁相關：頁**，頁合併，索引重建
語句相關：使用count(*),使用join的須知，使用group by 和order by 的須知，多用 limit，盡量不使用not in和like語句操作，union-all代替union。
事務相關：比如容易引起鎖競爭的行放在事務語句的後面。適當的選取事務隔離級別也對優化有幫助。
分庫分表：怎麼分庫分表？
找到瓶頸所在：檢視是什麼占用比較高，explain (這個過程都得根據實際去區分了)
參考：並不一定都用varchar最好，因為varchar是變長的，因為變長所以可能會因為後續資料變大了導致乙個行占用空間增加導致了頁**。
varchar適用的場景：
varchar的優點：
varchar的缺點：
注意每乙個列都可以單獨指定他的字符集，如果他沒有複雜的中文，可以使用不是utf8來儲存。
varchar會多額外需要1到2個位元組儲存長度資訊，而且update可能會導致也**所以定長選擇char型別更好一點。
char適用的場景：
char的缺點：
如果有計數的需求，最好有個計數表。計數表如果有事務，最好是先插入再更新，影響事務的放後面。
對於 count(主鍵 id) 來說，innodb 引擎會遍歷整張表，把每一行的 id 值都取出來，返回給 server 層。server 層拿到 id 後，判斷是不可能為空的，就按行累加。
對於 count(1) 來說，innodb 引擎遍歷整張表，但不取值。server 層對於返回的每一行，放乙個數字「1」進去，判斷是不可能為空的，按行累加。 (這個1是個數字)也就是count(2)也一樣
count(1) 執行得要比 count(主鍵 id) 快。因為從引擎返回 id 會涉及到解析資料行，以及拷貝字段值的操作。
count(字段)還要判斷一下為不為null，然後進行累加。為null不累加。
[mysql]order by是怎麼工作的？
因為分為記憶體中全欄位排序和rowid排序（快速排序），以及如果記憶體被占用太大會使用歸併的檔案排序。
因為唯一索引在更新的時候，要把資料頁查出來，看看衝不衝突，然後在更新進去。盡量選取普通索引。用業務來保證唯一。所以唯一索引並不能用changebuffer。
所以如果是頻繁寫入更新的資料庫，盡量別使用唯一索引，建立普通索引就好~
更新的時候，如果資料頁在記憶體中，就會直接更新。如果沒在記憶體中，在不影響資料一致性的前提下，
innodb有著更新操作快取change buffer。
這個快取的特點，記憶體中有乙份 硬碟中也有乙份，是持久化的，
而且查詢到這個資料頁的時候，會進行吧這個change buffer merge進去，執行merge操作。
(ps:後台執行緒也會定期的merge這個change buffer到磁碟中)
change buffer 可以減少讀磁碟，執行速度會得到很大的提公升。
資料讀入到記憶體中占用buffer pool，這種方式可以避免占用記憶體，提高記憶體的佔用率，因為減少讀入記憶體的次數。
另外：資料從硬碟中讀入到記憶體是隨機io訪問，成本很高。
如果更新之後就要查詢的記錄，應該關閉change buffer。
切換的優化思路
切換的優化思路分兩種情況 1 切換不及時 可以臨時調整干擾小區的功率 後台調整 降低干擾小區的功率，使服務小區不覆蓋到該點位，調整後還要測量周圍區域是否收到影響 降低切換門限 後台調整 使該點位能夠在新小區訊號加強時及時切換過去。調整干擾小區的天線傾角或者方位角 這是根本的做法，通常要帶著塔工一起，...
mysql的優化思路
資料庫的優化是乙個大而逛之的概論，我們不能以上來就說該怎麼優化，而是需要確認資料庫的具體問題 1 觀察資料庫是否有週期性的效能變化，故障或者波動 如果存在是否是高峰的訪問，快取奔潰引起 加快取並更改快取失效的策略 2 用show processlist 或者開啟慢查詢，觀察有問題的sql proil...
mysql思路 MySQL優化思路
通過指令碼，重新整理觀察mysql的status，觀察是否有週期性故障活波動，一般由訪問高峰或者快取失效引起，家快取並更改快取失效策略，是失效時間分散或頁面定時失,show processlist顯示哪些執行緒正在執行。您也可以使用mysqladmin processlist語句得到此資訊。如果您有...