有没有专门做ppt的网站,潍坊手机网站建设,网页升级无法自动更新,科技小制作一等奖目录 一、前言二、表数据准备三、常见业务无索引查询耗时测试3.1、通过订单ID / 订单编号 查询指定订单3.2、查询订单列表 四、订单常见业务索引优化实践4.1、通过唯一索引和普通索引优化通过订单编号查询订单信息4.2、通过普通联合索引优化订单列表查询4.2.1、分析查询字段的查… 目录 一、前言二、表数据准备三、常见业务无索引查询耗时测试3.1、通过订单ID / 订单编号 查询指定订单3.2、查询订单列表 四、订单常见业务索引优化实践4.1、通过唯一索引和普通索引优化通过订单编号查询订单信息4.2、通过普通联合索引优化订单列表查询4.2.1、分析查询字段的查询场景4.2.2、优化各场景查询和原因分析4.2.2.1、需要根据订单编号查询4.2.2.2、需要根据客户编号查询4.2.2.3、需要根据创建时间查询 和 需要根据订单状态查询 五、索引优化实践4.1 联合索引第一个字段用范围查询可能不会走索引4.2 强制走索引联合索引第一个字段用范围查询不会走索引这里强制使用索引4.3 使用覆盖索引优化查询4.4 in和or在表数据量比较大的情况会走索引在表记录不多的情况下会选择全表扫描4.5 like KK% 一般情况也是可以走索引的4.6 分页查询索引使用和优化4.7 order by查询索引使用和优化4.7 总结 六、索引设计原则 一、前言 索引是为了高效查询排好序的数据结构当表数据量到达一个量级没有对应索引帮助查询耗时会很长MySQL资源开销也会非常大当然索引也不能随意创建要做到尽量少的索引解决尽量多的问题这里会对一些业务场景做索引优化演示这篇文中只介绍单表索引优化如果单表问题能解决多表关联查询优化就简单多了。
如果对MySQL索引原理还有explain SQL分析工具不是很熟悉的可以看看几篇文章
MySQL 索引底层 BTree 原理解析MySQL explain SQL分析工具详解与最佳实践MySQL 索引介绍和最佳实践
二、表数据准备
这里要准备100w数据左右的表表数据尽量多一些或者列多一些如果数据太少测试的时候可能看不到效果。
创建订单信息表
DROP TABLE IF EXISTS order_info;
CREATE TABLE order_info (id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 订单ID,order_no varchar(100) NOT NULL COMMENT 订单编号,customer_id bigint(20) NOT NULL COMMENT 客户编号,goods_id bigint(20) NOT NULL COMMENT 商品ID,goods_title varchar(100) DEFAULT NULL COMMENT 商品标题,order_status tinyint(4) NOT NULL DEFAULT 1 COMMENT 订单状态 1待支付 2已支付 3已发货 4、已收货,create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间,PRIMARY KEY (id)
) ENGINEInnoDB COMMENT订单信息表;使用存储过程插入100w条数据
## 创建一个插入数据的存储过程
DROP PROCEDURE IF EXISTS insert_procedure;
delimiter;;
CREATE PROCEDURE insert_procedure ()
BEGINDECLARE i INT DEFAULT 1;DECLARE goods_id BIGINT DEFAULT CEIL(RAND() * 100);DECLARE t_error INTEGER DEFAULT 0;DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET t_error1;START TRANSACTION;WHILE ( i 1000000 ) DOINSERT INTO order_info(order_no,customer_id, goods_id, goods_title, order_status, create_time) VALUES (CONCAT(ON00000,i), CEIL(RAND() * 100000), goods_id, CONCAT(笔记本电脑,goods_id), MOD(i, 4)1, NOW());SET i i 1;SET goods_id CEIL(RAND() * 100);END WHILE;IF t_error1 THENROLLBACK;ELSECOMMIT;END IF;
END;;
delimiter;# 调用存储过程插入数据 我本地插入100w条数据耗时200s
CALL insert_procedure ();三、常见业务无索引查询耗时测试
我电脑的配置32G内存500G固态MySQL配置全用默认自己测试先看看自己MySQL配置的innodb_buffer_pool_size设置的是多少默认是128MB查看命令SHOW VARIABLES LIKE innodb_buffer_pool_size;配置里的单位是字节InnoDB使用一个缓冲池来保存索引和原始数据innodb_buffer_pool_size就是控制这个缓冲池的大小这个缓冲池在一些情况下对查询性能影响非常大线上建议设置成MySQL能使用内存的80%这里不深入。
3.1、通过订单ID / 订单编号 查询指定订单
通过订单ID查询订单
SELECT * FROM order_info WHERE id 955;通过订单编号查询订单
SELECT * FROM order_info WHERE order_no ON000009999;这里已经可以看到查询耗时明显的差距我们这里的ID是主键MySQL InnoDB存储引擎会自动将表中的主键设置为主键索引同时也是一个聚簇索引叶子节点携带数据而订单编号是没有索引的会进行全表扫描会将ON000009999和这个表中每行数据的订单编号都进行比对然后取出满足条件的数据行100w数据查询一个订单信息耗时已经到了0.6秒左右。
3.2、查询订单列表
查询订单列表一般查询条件比较多如订单编号、客户编号、订单状态、创建时间、创建时间倒序、是否分页做几个演示查询条件的内容自己看看存储过程插入的数据长什么样。
1、查询客户编号为111的订单列表不分页不根据创建时间倒序
SELECT * FROM order_info WHERE customer_id 111 AND create_time 2023-10-02 09:57:24 AND create_time 2023-10-02 10:00:46;2、查询客户编号为111订单列表分页不根据创建时间倒序
SELECT * FROM order_info WHERE customer_id 111 AND create_time 2023-10-02 09:57:24 AND create_time 2023-10-02 10:00:46 LIMIT 3;3、查询客户编号为111订单列表分页根据创建时间倒序
SELECT * FROM order_info WHERE customer_id 111 AND create_time 2023-10-02 09:57:24 AND create_time 2023-10-02 10:00:46 ORDER BY create_time DESC LIMIT 3;这里三个查询只有第2个查询相对较快一点耗时110毫秒其它两个查询耗时基本上都接近500毫秒从我们给定的条件来看区别就在分页或者不分页排序或者不排序一般认为分页肯定比不分页查询要快但是我们看1和2查询分页比不分页耗时相差接近5倍相差可以说是巨大然后在查询3中分页但是根据创建时间倒序这里耗时和查询1相近和查询2耗时相差接近5倍这其中原理挺有趣的会在下面索引优化实践中举例说明这一些问题。
四、订单常见业务索引优化实践
这里会对一些业务场景举例说明也会对索引的一些特性做讲解。
4.1、通过唯一索引和普通索引优化通过订单编号查询订单信息
类似通过订单编号查询订单信息的业务有很多都是通过一个编号信息如客户编号配送员编号查询一个一对一的详情数据这一类查询都有一个特性编号唯一并且编号类的数据大多都是字符串类型这里优化可以考虑唯一索引和普通索引一般我们会给这一类编号数据设置一个唯一索引既保证了数据的唯一性也保证了通过编号查询的性能问题。
1、添加唯一索引
ALTER TABLE order_info ADD UNIQUE INDEX idx_orderNo(order_no);2、添加索引后查询
SELECT * FROM order_info WHERE order_no ON000009999;无索引测试的时候耗时0.538s添加索引后查询性能提升十几倍数据量越大提升比例越高。
4.2、通过普通联合索引优化订单列表查询 在上面无索引查询我们列举了查询订单列表的三个例子查询耗时除了第2个都差不多耗时0.5s不算太慢但是对MySQL性能开销其实是很大的如果数据量在大一些到500w 1000w查询时间也会增加到接受不了数值所以必须要优化。
4.2.1、分析查询字段的查询场景 优化前第一要考虑的就是需要一些什么字段如我们例子中会使用订单编号、客户编号、订单状态、创建时间。
分析通过这四个字段查询的场景
1、需要根据订单编号查询2、需要根据客户编号查询3、需要根据创建时间查询4、需要根据订单状态查询
这里我给这四个字段分了四个查询场景为什么这么分我在下面会详细说明。
4.2.2、优化各场景查询和原因分析
对于这种列表查询使用索引一定要知道索引的一个特性就是最左前缀原则索引的匹配一定是从最左边第一个字段开始匹配的不能跳过中间字段匹配在索引优化实践中会详细说明。
4.2.2.1、需要根据订单编号查询 在一个订单列表如果需要根据订单编号查询那么一定是要查询一个唯一的订单如果我们有索引那么我们可以通过一个订单编号快速定位到一条数据不用进行全表扫描竟然能快速定位到一条数据那么就算还携带别的条件那直接回表取出行数据再去判断即可。 所以这里只需要创建一个订单编号的索引来适配所有带订单编号的查询我们在本文的4.1的优化通过订单编号查询订单信息中创建过一个订单编号的唯一索引我们这里就用这个唯一索引就行。
1、需要根据订单编号查询测试
SELECT * FROM order_info WHERE order_no ON000009999 AND order_status4;执行计划 EXPLAIN
这里可以看到查询耗时为0.037s执行计划中使用到了订单编号的索引扫描估计行数为1。
4.2.2.2、需要根据客户编号查询 在需要根据客户编号查询的业务中一定是以客户编号为主要条件的还有可能会携带订单状态创建时间等一个客户可能会下很多单想想自己这些年网购和点外面应该也有个100单以上了把那么这里就不能像订单编号只用一个单字段索引了我们需要把订单状态和创建时间也加上其实就算不加性能也不会差太多因为一个客户订单本来也不会太多单表几十条数据和几百条数据查询差距不会很大。
1、创建以客户编号起头的普通联合索引
ALTER TABLE order_info ADD INDEX idx_customerId_orderStatus_createTime(customer_id, order_status, create_time);我这里会把订单状态和创建时间也带上某购物APP查询自己订单是不是都有状态选择时间字段可以用作排序和检索。
2、需要根据客户编号查询测试
SELECT * FROM order_info WHERE customer_id 111 AND order_status4 AND create_time 2023-10-02 09:57:24 AND create_time 2023-10-02 10:00:46;执行计划 EXPLAIN 这里可以看到使用到了我们创建的联合索引并且三个字段全用到了客户编号bigint类型不能为空占用8字节订单状态tinyint不能为空占用1字节创建时间datetime类型占用5个字节因为创建时间可为空所以多加一个字节创建时间占用6个字节合集15个字节和key_len相等。
4.2.2.3、需要根据创建时间查询 和 需要根据订单状态查询 在查询订单列表时经常会查询某个状态某个时间有多少订单状态值只有4个如果要通过状态值建立索引的话显然是不可行的通过状态索引查找某个类型数据可能得到的是几十万行数据然后还需要回表获取聚簇索引数据所以对于这种状态值创建单独索引时还需要带上时间字段在单独查询某个时间内全部订单时也可以使用这个索引通过in查询将状态值全部包含满足最左前缀原则就能使用该索引查询指定时间段的全部订单。
1、添加索引前查询某个时间段内全部订单
SELECT * FROM order_info WHERE order_status IN (1,2,3,4) AND create_time 2023-10-02 09:57:30 AND create_time 2023-10-02 09:57:31;因为我们是批量插入的时间间隔比较相近1秒有好几千条数据自己查询测试的时候最好控制区间在2s的样子。
2、创建订单状态和创建时间的普通索引
ALTER TABLE order_info ADD INDEX idx_orderStatus_createTime(order_status,create_time);3、查询某个时间段内全部状态订单
SELECT * FROM order_info WHERE order_status IN (1,2,3,4) AND create_time 2023-10-02 09:57:30 AND create_time 2023-10-02 09:57:40 ;执行计划 EXPLAIN 我们这里数据是批量插入的每秒会插入几千条数据查询时间间隔不能太大了最好在2s的样子不然索引可能是会失效的要查询某个状态的订单只有把订单状态的的IN查询换成查询效果是一样的满足最左前缀原则即可。
五、索引优化实践
在订单常见业务索引优化实践中简单的介绍了一下在一些场景下创建一些什么索引能提升查询效率但是还有很多可变因素会影响到索引的使用也有很多场景可以使用更好的索引以及索引中很重要的左前缀原则这里会对一些场景做举例说明。
删除之前创建的索引创建新的测试联合索引
# 删除上面创建的三个索引避免测试时被其它索引干扰要是没有创建则不用删除
ALTER TABLE order_info DROP INDEX idx_orderNo;
ALTER TABLE order_info DROP INDEX idx_customerId_orderStatus_createTime;
ALTER TABLE order_info DROP INDEX idx_orderStatus_createTime;
# 创建新的测试联合索引
ALTER TABLE order_info ADD INDEX idx_goodsTitle_customerId_orderStatus(goods_title, customer_id, order_status);4.1 联合索引第一个字段用范围查询可能不会走索引
EXPLAIN SELECT * FROM order_info WHERE goods_title 笔记本电脑9 AND customer_id 9 AND order_status 4;给一个区间值
EXPLAIN SELECT * FROM order_info WHERE goods_title 笔记本电脑9 AND goods_title 笔记本电脑99 AND customer_id 9 AND order_status 4;MySQL5.7
MySQL8.0
联合索引第一个字段就用范围查找可能不会走索引对于MySQL5.7来说只要第一个字段用范围查找不会走索引但是对于MySQL8.0来说给个查询区间还是可能会走索引的前提是区间也不能太大不然也不会走索引MySQL内部可能觉得第一个字段用范围结果集应该很大回表效率不高还不如就全表扫描创建联合索引时千万别把时间这类型字段放第一个了。
4.2 强制走索引联合索引第一个字段用范围查询不会走索引这里强制使用索引
EXPLAIN SELECT * FROM order_info FORCE INDEX(idx_goodsTitle_customerId_orderStatus) WHERE goods_title 笔记本电脑9 AND customer_id 9 AND order_status 4;这里确认是使用了我们指定的索引然后再来看看查询性能怎么样 不指定强制走索引 指定强制走索引
经过对比发现强制走索引查询时间能缩短近10倍所以有时候MySQL自身并不一定能选择到性能最高的索引使用方式需要自己不断的尝试对比出最好的方式。
4.3 使用覆盖索引优化查询
EXPLAIN SELECT goods_title,customer_id,order_status FROM order_info WHERE goods_title 笔记本电脑9 AND customer_id 9 AND order_status 4;查询结果字段和条件字段都在同一个索引中查询可以完全使用索引中字段不用回表则称为覆盖索引覆盖索引因为能避免回表就算联合索引第一个字段范围查询也能走索引。
4.4 in和or在表数据量比较大的情况会走索引在表记录不多的情况下会选择全表扫描
100w数据表测试
EXPLAIN SELECT * FROM order_info WHERE goods_title IN(笔记本电脑8,笔记本电脑9) AND customer_id 9 AND order_status 4;EXPLAIN SELECT * FROM order_info WHERE (goods_title 笔记本电脑8 OR goods_title 笔记本电脑9) AND customer_id 9 AND order_status 4;根据order_info创建一个只有3条数据order_info_copy表进行测试 MySQL5.7 MySQL8.0
这里可以看到MySQL5.7中会进行全表扫描但是MySQL8.0还是会走索引现在MySQL8.0市场上用的已经比较多了它执意要走索引肯定有它的道理而且要通过索引优化查询肯定是要测试比较查询效率的在实际业务中多测试再看看执行计划只要实践才知道加的索引是否好用。
4.5 like KK% 一般情况也是可以走索引的
like 笔记本电脑999
EXPLAIN SELECT * FROM order_info WHERE goods_title LIKE 笔记本电脑999% AND customer_id 9 AND order_status 4;like 笔记本电脑9
EXPLAIN SELECT * FROM order_info WHERE goods_title LIKE 笔记本电脑9% AND customer_id 9 AND order_status 4;使用like前缀查询在结果集较少的时候是会走索引的如果MySQL认为结果集较大还是不会走索引结合以上几个例子可以看出如果通过索引查询响应结果集过大并且没有满足覆盖索引也很有可能不会走索引这点MySQL5.0 8.0都是一样的。
4.6 分页查询索引使用和优化
例1在没有索引且不分页的请求下查询指定客户订单列表数据
EXPLAIN SELECT * FROM order_info WHERE customer_id 9 ORDER BY goods_title;例2在没有索引分页查询指定客户订单列表数据
SELECT * FROM order_info WHERE customer_id 9 LIMIT 0,3;SELECT * FROM order_info WHERE customer_id 9 LIMIT 80,3;通过这两个分页查询可以看到查询从第0条开始往后查3条数据执行耗时很短查询从第80条开始往后查3条数据耗时和不分页差不多因为MySQL分页查询的时候会根据我们的分页条件找出对应结果集的数据比如我们分页条件时customer_id 9 LIMIT 0,3MySQL会先用customer_id 9去一条条对比数据因为我们的分页参数时0,3也就是说找出3条数据即可只要找到了3条数据就不会往后找了同理LIMIT 80,3的时候需要找到83条数据就不会往后找了所以这里我们LIMIT 80,3的时候和不分页耗时差不了多少不加分页会扫描全表拿出全表的数据。
例3在没有索引分页查询指定客户订单列表数据并且根据创建时间排序
SELECT * FROM order_info WHERE customer_id 9 ORDER BY create_time LIMIT 0,3;这里加了一个排序条件分页查询后耗时也和不分页差不多因为如果加了排序字段是需要先扫全表获取全部符合结果的数据才能进行分页。
例4创建索引分页查询指定客户订单列表数据并且根据创建时间排序正序
# 创建索引
ALTER TABLE order_info ADD INDEX idx_customerId_createTime(customer_id, create_time);
# 删除索引
ALTER TABLE order_info DROP INDEX idx_customerId_createTime;SELECT * FROM order_info WHERE customer_id 9 ORDER BY create_time LIMIT 0,3;执行计划 EXPLAIN 创建索引后查询快了很多因为这里是正序的索引默认也是正序的根本不用在进行排序下面再试试倒序。
例4创建索引分页查询指定客户订单列表数据并且根据创建时间排序倒序
SELECT * FROM order_info WHERE customer_id 9 ORDER BY create_time DESC LIMIT 0,3;MySQL 5.7 MySQL8.0 查询时间和正序差不多但是这里MySQL5.7和MySQL8.0的Extra有点区别MySQL8.0可以反向索引扫描MySQL5.7应该是将获取到的数据放入内存中排序也可以创建倒序索引这里不深入。
4.7 order by查询索引使用和优化
例1
EXPLAIN SELECT * FROM order_info WHERE goods_title 笔记本电脑9 AND order_status 4 ORDER BY customer_id;利用最左前缀原则中间字段不能断因此查询用到了goods_title索引从key_len403也能看出customer_id索引列用在排序过程中因为Extra字段里没有using filesort而且索引本来就是正序的无需在排。
列2
EXPLAIN SELECT * FROM order_info WHERE goods_title 笔记本电脑9 ORDER BY order_status;从explain的执行结果来看key_len403查询使用了goods_title 索引由于用了order_status进行排序跳过了 customer_id出现了Using filesort。
列3
EXPLAIN SELECT * FROM order_info WHERE goods_title 笔记本电脑9 ORDER BY customer_id,order_status;查找只用到索引goods_title 字段customer_id和order_status用于排序无Using filesort。
列4
EXPLAIN SELECT * FROM order_info WHERE goods_title 笔记本电脑9 ORDER BY order_status,customer_id;和例3中explain的执行结果一样但是出现了Using filesort因为索引的创建顺序为goods_title,customer_id,order_status但是排序的时候customer_id和order_status颠倒位置了。
列5
EXPLAIN SELECT * FROM order_info WHERE goods_title 笔记本电脑9 AND customer_id 9 ORDER BY order_status,customer_id;与例4对比在Extra中并未出现Using filesort因为customer_id 为常量在排序中被优化所以索引未颠倒不会出现Using filesort。
列6
EXPLAIN SELECT * FROM order_info WHERE goods_title 笔记本电脑9 ORDER BY customer_id ASC,order_status DESC;虽然排序的字段列与索引顺序一样且order by默认升序这里position desc变成了降序导致与索引的排序方式不同从而产生Using filesort。
列7
EXPLAIN SELECT * FROM order_info WHERE goods_title IN (笔记本电脑9,笔记本电脑10) ORDER BY customer_id,order_status;对于排序来说IN查询也是范围查询如果排序查询中使用范围查询则索引中只能用到goods_title后面的字段无法使用。
列8
EXPLAIN SELECT * FROM order_info WHERE goods_title 笔记本电脑9 ORDER BY goods_title;MySQL5.7
MySQL8.0 MySQL5.7只要是联合索引第一个字段要走范围查询那么索引就没法使用除非覆盖索引但是在MySQL8.0时却是会去使用索引的还可以对比一下查询性能我这里MySQL5.7全表扫描耗时1.3sMySQL8.0走索引耗时0.8s两个版本MySQL第一次执行可能时间都需要2s的样子会将磁盘中的聚簇索引叶子节点数据加载到内存中多次执行后回表可以直接查内存不用再次读取磁盘。
4.7 总结
1、MySQL支持两种方式的排序filesort和indexUsing index是指MySQL扫描索引本身完成排序。index 效率高filesort效率低。2、order by满足两种情况会使用Using index。 order by语句使用索引最左前列。使用where子句与order by子句条件列组合满足索引最左前列。 3、尽量在索引列上完成排序遵循索引建立索引创建的顺序时的最左前缀法则。4、如果order by的条件不在索引列上就会产生Using filesort。5、能用覆盖索引尽量用覆盖索引6、group by与order by很类似其实质是先排序后分组遵照索引创建顺序的最左前缀法则。对于group by的优化如果不需要排序的可以加上order by null禁止排序。注意where高于having能写在where中 的限定条件就不要去having限定了。
Using filesort文件排序原理详解
filesort文件排序方式 单路排序是一次性取出满足条件行的所有字段然后在sort buffer中进行排序用trace工具可 以看到sort_mode信息里显示 sort_key, additional_fields 或者 sort_key, packed_additional_fields 双路排序又叫回表排序模式是首先根据相应的条件取出相应的排序字段和可以直接定位行 数据的行 ID然后在 sort buffer 中进行排序排序完后需要再次取回其它需要的字段用trace工具 可以看到sort_mode信息里显示 sort_key, rowid MySQL 通过比较系统变量 max_length_for_sort_data(默认1024字节) 的大小和需要查询的字段总大小来 判断使用哪种排序模式。 如果 字段的总长度小于max_length_for_sort_data 那么使用 单路排序模式如果 字段的总长度大于max_length_for_sort_data 那么使用 双路排序模式。
六、索引设计原则
1、代码先行索引后上 不知大家一般是怎么给数据表建立索引的是建完表马上就建立索引吗 这其实是不对的一般应该等到主体业务功能开发完毕把涉及到该表相关sql都要拿出来分析之后再建立 索引。2、联合索引尽量覆盖条件 比如可以设计一个或者两三个联合索引(尽量少建单值索引)让每一个联合索引都尽量去包含sql语句里的 where、order by、group by的字段还要确保这些联合索引的字段顺序尽量满足sql查询的最左前缀原 则。3、不要在小基数字段上建立索引 索引基数是指这个字段在表里总共有多少个不同的值比如一张表总共100万行记录其中有个性别字段 其值不是男就是女那么该字段的基数就是2。 如果对这种小基数字段建立索引的话还不如全表扫描了因为你的索引树里就包含男和女两种值根本没 法进行快速的二分查找那用索引就没有太大的意义了。 一般建立索引尽量使用那些基数比较大的字段就是值比较多的字段那么才能发挥出B树快速二分查 找的优势来。4、长字符串我们可以采用前缀索引 尽量对字段类型较小的列设计索引比如说什么tinyint之类的因为字段类型较小的话占用磁盘空间也会 比较小此时你在搜索的时候性能也会比较好一点。 当然这个所谓的字段类型小一点的列也不是绝对的很多时候你就是要针对varchar(255)这种字段建立 索引哪怕多占用一些磁盘空间也是有必要的。 对于这种varchar(255)的大字段可能会比较占用磁盘空间可以稍微优化下比如针对这个字段的前20个 字符建立索引就是说对这个字段里的每个值的前20个字符放在索引树里类似于 KEY index(name(20),age,position)。 此时你在where条件里搜索的时候如果是根据name字段来搜索那么此时就会先到索引树里根据name 字段的前20个字符去搜索定位到之后前20个字符的前缀匹配的部分数据之后再回到聚簇索引提取出来 完整的name字段值进行比对。 但是假如你要是order by name那么此时你的name因为在索引树里仅仅包含了前20个字符所以这个排 序是没法用上索引的 group by也是同理。所以这里大家要对前缀索引有一个了解。5、where与order by冲突时优先where 在where和order by出现索引设计冲突时到底是针对where去设计索引还是针对order by设计索引到 底是让where去用上索引还是让order by用上索引? 一般这种时候往往都是让where条件去使用索引来快速筛选出来一部分指定的数据接着再进行排序。 因为大多数情况基于索引进行where筛选往往可以最快速度筛选出你要的少部分数据然后做排序的成本可 能会小很多。6、基于慢sql查询做优化 可以根据监控后台的一些慢sql针对这些慢sql查询做特定的索引优化。
