大表資料查詢
主從複製
讀寫分離
垂直拆分
水平切分
資料庫設計和查詢原則:
盡量設定主鍵
推薦使用自增id，不要使用uuid
字段定義為not null而不是null
密碼雜湊，鹽，使用者身份證號等固定長度的字串應該使用char而不是varchar來儲存，這樣可以節省空間且提高檢索效率。
避免犯如下sql語句錯誤
查詢不需要的資料。解決辦法：使用limit解決
多表關聯返回全部列。解決辦法：指定列名
總是返回全部列。解決辦法：避免使用select *
重複查詢相同的資料。解決辦法：可以快取資料，下次直接讀取快取
是否在掃瞄額外的記錄。解決辦法：
使用explain進行分析，如果發現查詢需要掃瞄大量的資料，但只返回少數的行，可以通過如下技巧去優化：
使用索引覆蓋掃瞄，把所有的列都放到索引中，這樣儲存引擎不需要回表獲取對應行就可以返回結果。
改變資料庫和表的結構，修改資料表正規化
優化長難的查詢語句
一次性刪除1000萬的資料要比一次刪除1萬，暫停一會的方案更加損耗伺服器開銷。
分解關聯查詢，讓快取的效率更高。
執行單個查詢可以減少鎖的競爭。
count(*)會忽略所有的列，直接統計所有列數，不要使用count(列名)
myisam中，沒有任何where條件的count(*)非常快。
當有where條件時，myisam的count統計不一定比其它引擎快。
確定on或者using子句中是否有索引。
確保group by和order by只有乙個表中的列，這樣mysql才有可能使用索引。
優化group by和distinct
這兩種查詢據可以使用索引來優化，是最有效的優化方法
如果不需要order by，進行group by時加order by null，mysql不會再進行檔案排序。
limit偏移量大的時候，查詢效率較低
可以記錄上次查詢的最大id，下次查詢時直接根據該id來查詢
union all的效率高於union
應盡量避免在 where 子句中使用!=或<>操作符，否則引擎將放棄使用索引而進行全表掃瞄。
應盡量避免在 where 子句中使用or 來連線條件，否則將導致引擎放棄使用索引而進行全表掃瞄，如：
select id from t where num=10 or num=20
-- 可以這樣查詢：
select id from t where num=10 union all select id from t where num=20
in 和 not in 也要慎用，否則會導致全表掃瞄，如：
select id from t where num in(1,2,3)
-- 對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
下面的查詢也將導致全表掃瞄：select id from t where name like 『%李%』若要提高效率，可以考慮全文檢索。
如果在 where 子句中使用引數，也會導致全表掃瞄。因為sql只有在執行時才會解析區域性變數，但優化程式不能將訪問計畫的選擇推遲到執行時；它必須在編譯時進行選擇。然 而，如果在編譯時建立訪問計畫，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃瞄：
select id from t where num=@num
-- 可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
應盡量避免在 where 子句中對字段進行表示式操作，這將導致引擎放棄使用索引而進行全表掃瞄。如：
select id from t where num/2=100
-- 應改為:
select id from t where num=100*2
應盡量避免在where子句中對字段進行函式操作，這將導致引擎放棄使用索引而進行全表掃瞄。如：
select id from t where substring(name,1,3)=』abc』
-- name以abc開頭的id應改為:
select id from t where name like 『abc%』
不要在 where 子句中的「=」左邊進行函式、算術運算或其他表示式運算，否則系統將可能無法正確使用索引。
沒有掌握的部分:
正規化是什麼意思？
超大分頁優化
explain就是在執行sql語句前面加個explain,mysql執行的時候會出乙個"執行分析"
慢查詢的優化首先要搞明白慢的原因是什麼？是查詢條件沒有命中索引？是load了不需要的資料列？還是資料量太大？
reference:
[1]mysql面試題-sql優化
mysql 大表優化 持續更新
單錶優化 除非單錶資料未來會一直不斷 否則不要一開始就考慮拆分，拆分會帶來邏輯 部署 運維的各種複雜度，一般以整型值為主的表在千萬級以下，字串為主的表在五百萬以下是沒有太大問題的。而事實上很多時候mysql單錶的效能依然有不少優化空間，甚至能正常支撐千萬級以上的資料量 字段 索引 查詢sql 總結 ...
mysql優化理解筆記（持續更新）
目前最常見的是innodb和myisam兩個儲存引擎 1 innodb 支援事務處理，提供行級鎖 外來鍵約束索引，行鎖 2 myisam 支援全文搜尋，表鎖 對於經常需要增刪改操作的表建議使用innodb，因為有事務處理 要麼成功要麼失敗回滾 而需要大量查詢操作的表建議用myisam 索引可以大大提...
SQL效能優化 持續更新中。。。。。。
1 通過rowid訪問表 索引 你可以採用基於rowid的訪問方式情況,提高訪問表的效率,rowid包含了表中記錄的物理位置資訊.oracle採用索引 index 實現了資料和存放資料的物理位置 rowid 之間的聯絡.通常索引提供了快速訪問rowid的方法,因此那些基於索引列的查詢就可以得到效能上...