Mysql索引型別建立錯誤導致SQL查詢緩慢
索引型別建立錯誤導致SQL查詢緩慢
透過pt-query-digest分析發現這條語句%95都需要15S以上
# Query 2: 0.00 QPS, 0.01x concurrency, ID 0xB0328811156CFA43 at byte 28152292
# This item is included in the report because it matches --limit.
# Scores: V/M = 1.67
# Time range: 2017-01-17 20:02:15 to 2017-03-02 14:48:20
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 7 2669
# Exec time 22 24668s 3s 20s 9s 15s 4s 9s
# Lock time 2 655ms 117us 1ms 245us 348us 68us 224us
# Rows sent 0 2.61k 1 1 1 1 0 1
# Rows examine 9 40.04M 9.46k 20.30k 15.36k 19.40k 3.60k 15.96k
# Rows affecte 0 0 0 0 0 0 0 0
# Bytes sent 0 172.03k 66 66 66 66 0 66
# Query size 2 560.39k 215 215 215 215 0 215
# String:
# Databases ebiz_kly
# Hosts 10.111.124.41
# Last errno 0
# Users ebiz_kly
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s ################################################################
# 10s+ ########################################################
# Tables
# SHOW TABLE STATUS FROM `ebiz_kly` LIKE 'ORDER_INFO'\G
# SHOW CREATE TABLE `ebiz_kly`.`ORDER_INFO`\G
# SHOW TABLE STATUS FROM `ebiz_kly` LIKE 'ORDER_CHECK'\G
# SHOW CREATE TABLE `ebiz_kly`.`ORDER_CHECK`\G
# EXPLAIN /*!50100 PARTITIONS*/
SELECT count(1) from (
SELECT a.* from ORDER_INFO a LEFT JOIN ORDER_CHECK b ON a.ORDER_NO=b.ORDER_NO
WHERE a.DELETED = '0'
GROUP BY a.id
ORDER BY a.CREATE_TIME DESC, a.MODIFIED_TIME DESC
) as t\G
手動執行檢視計劃
+----+-------------+------------+------+------------------+------+---------+------+----------+----------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+------+------------------+------+---------+------+----------+----------------------------------------------------+
| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 26682118 | NULL |
| 2 | DERIVED | b | ALL | ORDER_NO | NULL | NULL | NULL | 5182 | Using temporary; Using filesort |
| 2 | DERIVED | a | ALL | PRIMARY,ORDER_NO | NULL | NULL | NULL | 5149 | Using where; Using join buffer (Block Nested Loop)
order_info 跟order_check join 竟然這麼多返回行
兩張表的資料,每張表才5000多條
檢視兩張表(ORDER_INFO,ORDER_CHECK)欄位ORDER_NO竟然是full text index
修改索引型別發現只要0.3了.
system@localhost 17:45: [ebiz_kly]> SELECT count(1) from (
-> SELECT a.* from ORDER_INFO a LEFT JOIN ORDER_CHECK b ON a.ORDER_NO=b.ORDER_NO
->
-> WHERE a.DELETED = '0'
-> GROUP BY a.id
-> ORDER BY a.CREATE_TIME DESC, a.MODIFIED_TIME DESC
->
-> ) as t\G
*************************** 1. row ***************************
count(1): 5205
1 row in set (0.28 sec)
查詢執行計劃
system@localhost 17:45: [ebiz_kly]> explain SELECT count(1) from (
-> SELECT a.* from ORDER_INFO a LEFT JOIN ORDER_CHECK b ON a.ORDER_NO=b.ORDER_NO
->
-> WHERE a.DELETED = '0'
-> GROUP BY a.id
-> ORDER BY a.CREATE_TIME DESC, a.MODIFIED_TIME DESC
->
-> ) as t;
+----+-------------+------------+-------+-------------------+-----------+---------+---------------------+------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+-------------------+-----------+---------+---------------------+------+----------------------------------------------+
| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 5157 | NULL |
| 2 | DERIVED | a | index | PRIMARY,idx_oi_on | PRIMARY | 8 | NULL | 5157 | Using where; Using temporary; Using filesort |
| 2 | DERIVED | b | ref | idx_oc_on | idx_oc_on | 768 | ebiz_kly.a.ORDER_NO | 1 | Using where |
差距很明顯了
官方文件相關解決
全文索引
InnoDB FULLTEXT Indexes
FULLTEXT indexes are created on text-based columns (CHAR, VARCHAR, or TEXT columns) to help speed up queries and DML operations on data contained within those columns,
omitting any words that are defined as stopwords.
InnoDB FULLTEXT indexes have an inverted index design. Inverted indexes store a list of words, and for each word, a list of documents that the word appears in. To support
proximity search, position information for each word is also stored, as a byte offset.
全文索引建立基於文字的列(char,varchar,或文字列)來幫助加快對包含在這些列的資料查詢和DML操作,主要支援
關於全文索引解釋,阿里月報相關資料
透過pt-query-digest分析發現這條語句%95都需要15S以上
# Query 2: 0.00 QPS, 0.01x concurrency, ID 0xB0328811156CFA43 at byte 28152292
# This item is included in the report because it matches --limit.
# Scores: V/M = 1.67
# Time range: 2017-01-17 20:02:15 to 2017-03-02 14:48:20
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 7 2669
# Exec time 22 24668s 3s 20s 9s 15s 4s 9s
# Lock time 2 655ms 117us 1ms 245us 348us 68us 224us
# Rows sent 0 2.61k 1 1 1 1 0 1
# Rows examine 9 40.04M 9.46k 20.30k 15.36k 19.40k 3.60k 15.96k
# Rows affecte 0 0 0 0 0 0 0 0
# Bytes sent 0 172.03k 66 66 66 66 0 66
# Query size 2 560.39k 215 215 215 215 0 215
# String:
# Databases ebiz_kly
# Hosts 10.111.124.41
# Last errno 0
# Users ebiz_kly
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s ################################################################
# 10s+ ########################################################
# Tables
# SHOW TABLE STATUS FROM `ebiz_kly` LIKE 'ORDER_INFO'\G
# SHOW CREATE TABLE `ebiz_kly`.`ORDER_INFO`\G
# SHOW TABLE STATUS FROM `ebiz_kly` LIKE 'ORDER_CHECK'\G
# SHOW CREATE TABLE `ebiz_kly`.`ORDER_CHECK`\G
# EXPLAIN /*!50100 PARTITIONS*/
SELECT count(1) from (
SELECT a.* from ORDER_INFO a LEFT JOIN ORDER_CHECK b ON a.ORDER_NO=b.ORDER_NO
WHERE a.DELETED = '0'
GROUP BY a.id
ORDER BY a.CREATE_TIME DESC, a.MODIFIED_TIME DESC
) as t\G
手動執行檢視計劃
+----+-------------+------------+------+------------------+------+---------+------+----------+----------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+------+------------------+------+---------+------+----------+----------------------------------------------------+
| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 26682118 | NULL |
| 2 | DERIVED | b | ALL | ORDER_NO | NULL | NULL | NULL | 5182 | Using temporary; Using filesort |
| 2 | DERIVED | a | ALL | PRIMARY,ORDER_NO | NULL | NULL | NULL | 5149 | Using where; Using join buffer (Block Nested Loop)
order_info 跟order_check join 竟然這麼多返回行
兩張表的資料,每張表才5000多條
檢視兩張表(ORDER_INFO,ORDER_CHECK)欄位ORDER_NO竟然是full text index
修改索引型別發現只要0.3了.
system@localhost 17:45: [ebiz_kly]> SELECT count(1) from (
-> SELECT a.* from ORDER_INFO a LEFT JOIN ORDER_CHECK b ON a.ORDER_NO=b.ORDER_NO
->
-> WHERE a.DELETED = '0'
-> GROUP BY a.id
-> ORDER BY a.CREATE_TIME DESC, a.MODIFIED_TIME DESC
->
-> ) as t\G
*************************** 1. row ***************************
count(1): 5205
1 row in set (0.28 sec)
查詢執行計劃
system@localhost 17:45: [ebiz_kly]> explain SELECT count(1) from (
-> SELECT a.* from ORDER_INFO a LEFT JOIN ORDER_CHECK b ON a.ORDER_NO=b.ORDER_NO
->
-> WHERE a.DELETED = '0'
-> GROUP BY a.id
-> ORDER BY a.CREATE_TIME DESC, a.MODIFIED_TIME DESC
->
-> ) as t;
+----+-------------+------------+-------+-------------------+-----------+---------+---------------------+------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+-------------------+-----------+---------+---------------------+------+----------------------------------------------+
| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 5157 | NULL |
| 2 | DERIVED | a | index | PRIMARY,idx_oi_on | PRIMARY | 8 | NULL | 5157 | Using where; Using temporary; Using filesort |
| 2 | DERIVED | b | ref | idx_oc_on | idx_oc_on | 768 | ebiz_kly.a.ORDER_NO | 1 | Using where |
差距很明顯了
官方文件相關解決
全文索引
InnoDB FULLTEXT Indexes
FULLTEXT indexes are created on text-based columns (CHAR, VARCHAR, or TEXT columns) to help speed up queries and DML operations on data contained within those columns,
omitting any words that are defined as stopwords.
InnoDB FULLTEXT indexes have an inverted index design. Inverted indexes store a list of words, and for each word, a list of documents that the word appears in. To support
proximity search, position information for each word is also stored, as a byte offset.
全文索引建立基於文字的列(char,varchar,或文字列)來幫助加快對包含在這些列的資料查詢和DML操作,主要支援
關於全文索引解釋,阿里月報相關資料
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/24486203/viewspace-2134615/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- sql最佳化-錯誤強制型別轉換導致索引失效SQL型別索引
- CHAR型別函式索引導致結果錯誤型別函式索引
- 統計資訊過期導致SQL進行NESTED LOOPS查詢緩慢SQLOOP
- mysql慢查詢和錯誤日誌分析MySql
- Oracle資料庫非同步IO導致查詢響應緩慢Oracle資料庫非同步
- Mysql表關聯欄位未建索引導致查詢慢,優化後查詢效率顯著提升MySql索引優化
- [20181130]hash衝突導致查詢緩慢.txt
- MySQL:RR模式下insert也可能導致查詢慢MySql模式
- MySQL5.7 JSON型別列建立索引查詢一例MySqlJSON型別索引
- 多餘索引導致explain錯誤索引AI
- MySQL索引原理及慢查詢優化MySql索引優化
- 筆記 mongo查詢慢日誌,建立索引筆記Go索引
- 《MySQL慢查詢優化》之SQL語句及索引優化MySql優化索引
- Laravel 對於 Mysql 欄位string型別查詢,當使用數字對這個欄位進行查詢,PHP弱型別語言導致索引失效LaravelMySql型別PHP索引
- MySQL索引原理及慢查詢最佳化MySql索引
- SQL SERVER中什麼情況會導致索引查詢變成索引掃描SQLServer索引
- mysql查詢效率慢的SQL語句MySql
- MongoDB慢查詢與索引MongoDB索引
- MySQL 慢查詢MySql
- MySQL慢查詢MySql
- SQL調優--表統計資訊未及時更新導致查詢超級慢SQL
- 在mysql查詢效率慢的SQL語句MySql
- dba_jobs_running查詢緩慢
- Oracle隱式型別轉換導致索引失效Oracle型別索引
- 找出Mysql查詢速度慢的SQL語句MySql
- SQL慢查詢排查思路SQL
- Linux下mysql配置慢日誌查詢,把查詢慢的sql記錄下來LinuxMySql
- 查詢索引 常用SQL索引SQL
- mysql效能優化-慢查詢分析、優化索引和配置MySql優化索引
- 走索引掃描的慢查詢索引
- 並行查詢緩慢的問題分析並行
- 查詢DBA_HIST_ACTIVE_SESS_HISTORY緩慢
- MySQL 因資料型別轉換導致執行計劃使用低效索引MySql資料型別索引
- 繫結變數,組合查詢方式,導致CBO錯誤一例變數
- MySQL 慢查詢優化MySql優化
- MySQL:慢查詢日誌MySql
- Mysql慢查詢操作梳理MySql
- MySQL開啟慢查詢MySql