兩張表內連查詢，一張表1W+數據，一張表2000+數據，count一下居然花了10秒

這條語句： SELECT COUNT(a.id) FROM t_owneroffice a INNER JOIN t_member b ON (a.posterId = b.id) WHERE 1=1 AND a.type=1;

先看下索引情況吧

+---------------+------------+-------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |

+---------------+------------+-------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

| t_owneroffice | 0 | PRIMARY | 1 | id | A | 13249 | NULL | NULL | | BTREE | |

| t_owneroffice | 1 | FKE946FE4F2D5E109 | 1 | posterId | A | 1 | NULL | NULL | YES | BTREE | |

+---------------+------------+-------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

t_owneroffice 兩個索引，一個主鍵索引，一個普通索引

t_member 就一個主鍵索引

來看下語句解釋情況：

mysql> explain SELECT COUNT(a.id) FROM t_owneroffice a INNER JOIN t_member b ON (a.posterId = b.id) WHERE 1=1 AND a.type=1;

+----+-------------+-------+-------+-------------------+---------+---------+------+-------+--------------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+-------+-------+-------------------+---------+---------+------+-------+--------------------------------+

| 1 | SIMPLE | b | index | NULL | PRIMARY | 102 | NULL | 2045 | Using index |

| 1 | SIMPLE | a | ALL | FKE946FE4F2D5E109 | NULL | NULL | NULL | 13343 | Using where; Using join buffer |

+----+-------------+-------+-------+-------------------+---------+---------+------+-------+--------------------------------+

a表用了全表查詢，沒使用索引啊，之前是ref不是all，貌似插了幾百條數據之后就變成了all

看下執行情況

+--------------------+----------+----------+------------+

| Status | Duration | CPU_user | CPU_system |

+--------------------+----------+----------+------------+

| starting | 0.000082 | 0.000000 | 0.000000 |

| Opening tables | 0.000018 | 0.000000 | 0.000000 |

| System lock | 0.000007 | 0.000000 | 0.000000 |

| Table lock | 0.000009 | 0.000000 | 0.000000 |

| init | 0.000039 | 0.000000 | 0.000000 |

| optimizing | 0.000020 | 0.000000 | 0.000000 |

| statistics | 0.000020 | 0.000000 | 0.000000 |

| preparing | 0.000029 | 0.000000 | 0.000000 |

| executing | 0.000006 | 0.000000 | 0.000000 |

| Sending data | 9.379993 | 9.376574 | 0.000000 |

| end | 0.000010 | 0.000000 | 0.000000 |

| query end | 0.000002 | 0.000000 | 0.000000 |

| freeing items | 0.000328 | 0.000000 | 0.000000 |

| logging slow query | 0.000004 | 0.000000 | 0.000000 |

| cleaning up | 0.000003 | 0.000000 | 0.000000 |

+--------------------+----------+----------+------------+

時間全花在了Sending data上，為什么呢？? 一條count語句花了9秒啊，親，快來幫我看看啊

問題補充：

7454103 寫道

是否能使用上索引 和數據量沒太多的關系，

多看下你的查詢條件，

引用

WHERE 1=1

這樣寫貌似就不會使用索引的！

不是where的原因，貌似跟mysql配置有關系

你看時間全花在 Sending data上，但是這種情況一天會間歇的出現幾次

大部分時間是沒有問題的，可能高峰期間會出現這種問題

總結

以上是生活随笔為你收集整理的mysql中文时好时坏_mysql索引的问题，时好时坏的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。