mysql优化
1. where 语句后面字段是索引,查询时就用到索引
order by 字段是索引,而且 select 中都是索引字段,查询才使用了索引
select id,content from cloudnetwork order by name asc limit 8050,10;
发现执行这条语句本身需要12s左右,至此,问题基本已经定位,分页查询的原语需要优化。接着, 我们使用explain进一步查看执行计划
mysql> explain select id,content from cloudnetwork order by name asc limit 8050,10;
+----+-------------+--------------+------------+------+---------------+------+---------+------+------+----------+-----+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------------+------------+------+---------------+------+---------+------+------+----------+-----+
| 1 | SIMPLE | cloudnetwork | NULL | ALL | NULL | NULL | NULL | NULL | 1 | 100.00 | Using filesort |
+----+-------------+--------------+------------+------+---------------+------+---------+------+------+----------+-----+
我们发现key字段为null,key字段显示mysql实际决定使用的key,如果没有所以被选择,键就是null。这说明我们上面的原因查询过程中没有用到索引,一个高效的查询语句肯定是要带索引的,我们找到了可以优化的方向。
再看下表结构,分析这张表有哪些索引:
mysql> desc cloudnetwork;
+-------------------------+--------------+------+-----+---------+-------------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------------+--------------+------+-----+---------+-------------------+
| id | varchar(128) | NO | PRI | NULL | |
| content | longtext | YES | | NULL | |
| version | varchar(128) | YES | | NULL | |
| name | varchar(128) | YES | MUL | NULL | VIRTUAL GENERATED |
| vdcId | varchar(128) | YES | MUL | NULL | VIRTUAL GENERATED |
| vdcName | varchar(128) | YES | MUL | NULL | VIRTUAL GENERATED |
+-------------------------+--------------+------+-----+---------+-------------------+
发现id,name是有索引的,content 不是索引,我们在性能环境上执行下面的语句:
select id from cloudnetwork order by name asc limit 8050,10;
发现时间是ms级的,但返回的结果只有id(需要content,但content不是所以),我们可以用join连接查询解决这个问题。
select id,content from cloudnetwork inner join (select id from cloudnetwork order by name limit 8050, 10) tb1 using (id);

浙公网安备 33010602011771号