表資料，千萬
分頁查詢
但當 limit 子句變成 「limit 2000000,10」 時，既然要使用20秒。
要知道資料庫也並不知道第2000000條記錄從什麼地方開始，即使有索引也需要從頭計算一次。出現這種效能問題，多數情形下是程式設計師偷懶了。
索引：
如上圖並不能解決，分頁查詢的問題
解決的方案：我之前分享過的一篇文章《mysql分頁查詢優化》
sql語句中查詢變數和字段定義型別不匹配是另乙個常見的錯誤。例如
字段：索引：
其中字段 fd_frlist_paycardid 的定義為 varchar(200)，mysql 的策略是將字串轉換為數字之後再比較。函式作用於表字段，索引失效。
上述情況可能是應用程式框架自動填入的引數，而不是程式設計師的原意。現在應用框架很多很繁雜，使用方便的同時也小心它可能給自己挖坑。
mysql 不能利用索引進行混合排序。但在某些場景，還是有機會使用特殊方法提公升效能的。
執行計畫顯示為全表掃瞄.
由於 fd_morder_ispay 只有0和1兩種狀態，我們按照下面的方法重寫後。索引用上了。因表資料太少，效率的提公升不太明顯 從0.095秒 到 0.007秒
先上初始 sql 語句：
該sql語句原意是：先做一系列的左連線，然後排序取前15條記錄。從執行計畫也可以看出，最後一步估算排序記錄數為71萬，時間消耗: 8.000s。
由於最後 where 條件以及排序均針對最左主表，因此可以先對 tb_mall_order 排序提前縮小資料量再做左連線。sql 重寫後如下，執行時間縮小為1毫秒左右。
selecto.*
, a.
*from
(
selecto.*
from
tb_mall_order o
where fd_morder_ispay =
1order
byfd_morder_ispaytime
desc
limit 0,
15) o
join tb_mall_orderprodure op on o.fd_morder_id =
op.fd_morderp_morderid
left
join tb_author a on a.fd_author_id = o.fd_morder_authorid
再檢查執行計畫：子查詢物化後（select_type=derived)參與 join。雖然估算行掃瞄仍然為71萬，但是利用了索引以及 limit 子句後，實際執行時間變得很小。
上述提到的多數場景，在其它資料庫中也存在效能問題。了解資料庫編譯器的特性，才能避規其短處，寫出高效能的sql語句。
程式設計師在設計資料模型以及編寫sql語句時，要把演算法的思想或意識帶進來。
編寫複雜sql語句要養成使用 with 語句的習慣。簡潔且思路清晰的sql語句也能減小資料庫的負擔 。
Mysql之group by踩過的坑
mysql的group by分組是先排序後分組 對於使用者想要先排序後分組獲取最新的記錄，通過group by發現不可行 驗證步驟 1 建立乙個tt表進行驗證 create table tt id int 11 not null auto increment,num int 11 default n...
常見MySQL錯誤用法有哪些 小白怎麼學Web前端
常見mysql錯誤用法有哪些？小白怎麼學web前端？無論是前端開發還是後台應用，都需要掌握資料庫相關的知識，而mysql是企業常用的資料庫之一。對於乙個web前端小白來說，在完成html css的基礎學習後，他們還需要學習mysql相關操作，下面列舉幾種比較常見的mysql錯誤用法，希望大家能夠引以...
總結 linux安裝mysql踩過的坑。。。
總結 linux安裝mysql踩過的坑。舉例 使用的 mysql server and client 5.5.48 1.linux2.6.x86 64.rpm安裝 環境是centos7 安裝好依賴之後 繼續rpm ivh mysql server and client 5.5.48 1.linux2...