2） 排序字段没有建索引
3）
排序字段加DESC后索引没有起作用（如何让索引起作用才是关键、且听下文分解）
4）排序字段中加函数导致索引不起作用（这种一定要避免、本文不对这种情况展开说明）
5）排序字段中含有TEXT或CLOB字段（改成VARCHAR字段）
2. 用实例说明排序字段中增加DESC后索引不起作用、查询速度很慢
1）例如以下SQL、执行起来需要5秒左右、太慢不可接受：
SELECT T.WK_ID, T.WK_NAME, C.CR_CODE, T.AT_BEGIN_TIME, T.WK_BOOK
FROM BO_COPYRIGHT C
INNER JOIN ES_WORKS_INFO T
ON T.CR_ID = C.CR_ID
AND C.WK_ID_VALID = T.WK_ID
AND T. DELETEFLAG = 0
ORDER BY T.AT_BEGIN_TIME DESC, T.WK_BOOK
LIMIT 1, 100
其中 ES_WORKS_INFO 的AT_BEGIN_TIME 和WK_BOOK建有联合索引
2）性能慢的原因分析
实际上查看执行计划后发现索引没有起作用、Using where; Using filesort。
执行计划如下：
SIMPLE t ALL PRIMARY,idx_CR_ID 480006 Using where; Using filesort
SIMPLE c eq_ref PRIMARY,idx_WK_VALID PRIMARY 4 nrps.t.CR_ID 1 Using where
Using filesort
。是的，看到它，说明我们的查询需要优化了：文件排序是通过相应的排序算法，将取得的数据在内存中进行排序。联合索引没有起作用。将ORDER BY中的DESC去掉后执行完只要0.3秒。那为什么加了DESC后会变慢呢？业务要求必须加上DESC怎么办呢？
先来分析一下SQL执行慢的底层原因是什么？
我先查了一下复合索引的字段顺序和order by中的字段顺序是一致的、那为什么还是这么慢呢？为什么还是Using filesort？为什么索引不起作用呢？
MySql 索引创建手册里如是说：
索引列的定义可以跟随 ASC 或者 DESC。这些关键字允许为未来扩展用于指定升序或降序索引值存储。这个语法会被解析但却被忽略。索引列总是以升序排列。——也就是说你写了不会报错，但写了白写。
这样看来，我们的复合索引没起排序作用，原因就在于我们的索引中各字段 asc 存储， order by 里 desc 和 asc(默认是 asc) 混用。为了验证这个说法，我们把该 order by 各个字段换为一致的 desc试试:
SELECT T.WK_ID, T.WK_NAME, C.CR_CODE, T.AT_BEGIN_TIME, T.WK_BOOK
FROM BO_COPYRIGHT C
INNER JOIN ES_WORKS_INFO T
ON T.CR_ID = C.CR_ID
AND C.WK_ID_VALID = T.WK_ID
AND T. DELETEFLAG = 0
ORDER BY T.AT_BEGIN_TIME DESC, T.WK_BOOK DESC
LIMIT 1, 100
果然性能一下子提高了、执行时间0.3秒结束。
但是有个遗憾如果业务上必须要求一个字段DESC另一个字段ASC的话、这个SQL语句怎么优化能？有哪个大牛知道的话、请赐教！szwangdf@163.com
3.关于ORDER BY慢的情况下可以从以下几点进行优化：
1）ORDER BY的字段改到一种表、不要夸表（设计表结构时需注意这一点）
2）OEDER BY字段建索引、多个字段时建联合索引（联合索引的字段顺序要与ORSER BY中的字段顺序一致）
3）ORDER BY中字段中联合索引的所有字段DESC或ASC要统一，否则索引不起作用
4）不要对TEXT字段或者CLOB字段进行排序
4.以下是另一个技术大牛【陈小峰_iefreer】整理的跟ORDER BY有关的知识点
原文地址：https://blog.csdn.net/iefreer/article/details/12622097
1.mysql在数据量较大的时候、使用order by查询结果集时速度很慢的原因可能有以下几种：1） 排序字段没有建索引2）排序字段加DESC后索引没有起作用（如何让索引起作用才是关键、且听下文分解）3）排序字段中加函数导致索引不起作用（这种一定要避免、本文不对这种情况展开说明）2.用实例说明排序字段中增加DESC后索引不起作用、查询速度很慢1）例如以下SQL、执行起来需要5秒左右、太慢不可接受：...
在
MySQL
查询语句过程和EXPLAIN语句基本概念及其优化中介绍了EXPLAIN语句，并举了一个
慢
查询例子：
可以看到上述的查询需要检查1万多记录，并且使用了临时表和filesort排序，这样的查询在用户数快速增长后将成为噩梦。
在优化这个语句之前，我们先了解下SQL查询的基本执行过程：
1.应用通过
MySQL
API把查询命令发送给
MySQL
服务器，然后被解析
2.检查权限、
MySQL
optimizer进行优化，经过解析和优化后的查询命令被编译为CPU可运行的二进制形式的查询计划（query plan），并可以被缓存
3.如果存在索引，那么先扫描索引，如果数据被索引覆盖，那么不需要额外
因为可能需要对数据库的记录进行重新排序。在这篇文章中，笔者就谈谈提高
Order
By语句查询效率的两个思路，以供大家参考。
在
MySQL
数据库中，
Order
by语句的使用频率是比较高的。但是众所周知，在使用这个语句时，往往会降低数据查询的性能。因为可能需要对数据库的记录进行重新排序。在这篇文章中，笔者就谈谈提高
Order
By语句查询效率的两个思路，以供大家参考。
498)this.width=498;” b
order
=0>
一、建议使用一个索引来满足
Order
By子句。
在条件允许的情况下，笔者建议最好使用一个索引来满足
Order
By子句。如此的话，就可以避免额外的排序工作。这里笔
1、
order
by 索引（where条件中引用的索引）。
2、强制使用主键：FORCE INDEX(PRI)，如果想强制使用索引，则用FORCE INDEX(索引名)。
explain select t.
order
_id from book_
order
t FORCE INDEX(...
我解决的方法是使用FORCE INDEX强制使用索引，为tcug_datetime字段新建一个名字为tcug_datetime的索引（Normal BTREE）
SELECTa.tcug_datetime FROM manage.tb_crm_files_gj a FORCE INDEX(tcug_datetime)
LEFT JOI...
《Effective
MySQL
之
SQL语句
最优化》是由
MySQL
专家Ronald Bradford撰著，书
中提供了
很多
可以用于改进数据库和应用程序性能的最佳实践技巧，并对这些技巧
做了详细的解释。本书希望能够通过一步步详细介绍SQL优化的方法，帮助读者分
析和调优有问题的
SQL语句
。
● 找出收集和诊断问题必备的分析命令
● 创建
MySQL
索引来改进查询性能
● 掌握
MySQL
的查询执行计划
● 找出影响查询执行和性能的关键配置变量
● 用
SQL语句
优化的生命周期来识别、确
认、分析然后优化
SQL语句
，并检查优
● 学习使用不为常人所知的一些性能技巧
来改进索引效率并简化
SQL语句
2. 增加内存：如果服务器内存不足，
MySQL
可能需要使用临时表或磁盘排序，增加内存可以避免这种情况。
3. 减少数据量：使用`limit`语句可以限制结果集的数量，减小数据量可以提高查询速度。
4. 使用合适的存储引擎：不同的存储引擎具有不同的排序速度。如果排序是经常用到的，可以考虑使用更适合排序的存储引擎，如MyISAM或InnoDB。
5. 考虑使用替代方案：如果排序对于应用程序不是必需的，可以考虑替代方案，例如将排序操作放到应用程序层。
这些都是一些可以考虑的优化策略，但具体情况可能因数据库的不同而有所差异，希望这些信息对您有所帮助。
