mysql排序

order by 的排序优化 1、 ORDER BY 子句尽量使用index方式排序，避免使用filesort方式排序。 2、ORDER BY 满足两种方式会使用index方式排序： order by使用索引最左前列 使用where 子句与order by 子句条件列组合满足索引最左前列 3、如果不在索引列上，filesort有两种算法，mysql就要启动双路和单路排序. 双路排序 （1）mysql4.1之前是使用双路排序，两次扫描磁盘，最终得到数据，读取行指针和order by列，对他们进行排序，然后扫描已经排好序的列表，按照列表中的值重新从数据库列表中读取对应的数据输出。 （2）从磁盘读取字段，在buffer中进行排序，再从磁盘取其他字段。 （3）取一批数据，要扫描两次磁盘，进行两次I/O操作，由于I/O操作很耗时，索引在4.1之后采用另一种算法，单路排序。 单路排序 从磁盘中读取查询所需要的列，按照order by列在buffer进行排序，然后扫描排序后的列表进行输出，它的效率更高一点，避免了第二次读取数据。并且随机I/O变成了顺序I/O，但是它会使用更大的内存空间，因为它把数据都保存在内存当中。 注意 在sort buffer中，单路排序比双路排序使用了更多的内存空间，因为单路排序把所有字段都取出，所有有可能导致取出的数据总大小超出sort_buffer的容量

　　一次偶然的机会，发现在登陆验证时，改变用户名的大小写，同样可以登录成功，这是由于，当时使用的mysql数据库对大小写不敏感,查询时总是能查询到数据。一番查找资料，给出的原因是：在创建数据库的时候，选择了utf8_general_ci排序规则。 　　创建数据库时，需要同时选择字符集和排序规则，字符集大家都知道是怎么回事，那排序规则干嘛用的呢？ 　　排序规则：是指对指定字符集下不同字符的比较规则。其特征有以下几点： 　　　　1、 两个不同的字符集不能有相同的排序规则 　　　　2、 两个字符集有一个默认的排序规则 　　　　3、 有一些常用的命名规则：如_ci结尾表示大小写不敏感（caseinsensitive）,_cs表示大小写敏感（case sensitive）,_bin表示二进制的比较（binary）。 　　我用的是5.6版本的mysql，对于这个版本是不支持utf8的cs排序规则，如果要想对大小写敏感，可以使用_bin的排序规则。 　　与此同时，可以使用“show COLLATION;”查询当前版本的数据库支持的所有排序规则。使用 “show charset like 'utf8%';”进一步查看当前字符集的默认排序规则是什么。 　　对于_ci的规则，表示不区分大小写，如图所示: 　　对于使用_bin排序规则的查询如下: 　　　对于已经创建好的表,可以是用如下命令进行修改

对比可以发现5.7版本的MySql在执行这条sql时缺少了一个derived操作，通过查阅相关资料了解到MySql 5.7对子查询进行了优化，认为子查询中的order by可以进行忽略，只要Derived table里不包含如下条件就可以进行优化： UNION clause GROUP BY DISTINCT Aggregation LIMIT or OFFSET 这里把链接放上：5.7中Derived table变形记 最后放上相应的解决办法： --方法一，仅适用于低于5.7版本的MySql-- select * from (select * from shop order by price desc) a GROUP BY a.shop_name; --方法二-- select * from (select * from shop order by price desc limit 999999) a GROUP BY a.shop_name; --方法三-- select * from shop a where N > (select count(*) from shop b where b.shop_name = a.shop_name and a.price < b.price) order by a.shop_name,a.price desc; 1 2 3 4 5 6

索引是特殊的数据结构，它以易于遍历的形式存储部分集合数据集。索引存储特定字段或字段集的值，按字段值排序。 MongoDB的索引几乎与传统的关系型数据库索引一模一样，它的主键 _id 也是一个索引，MongoDB的数据按照 _id 的顺序存储在内存页与磁盘块上。但是， _id 与业务毫无关联，在业务相关的条件查询时，还是需要进行全表扫描才能找到对应页，效率并不高。 为了避免性能瓶颈，可以根据常用的查询建立索引 索引的值是按照一定的顺序排列的，使用索引键对文档进行排序效率非常高，只需要按照索引读取数据即可。 不过，使用索引也是有代价的，不仅会增加磁盘与内存的消耗，对于添加的每一个索引，每次写操作（插入、更新、删除）都会耗费更多时间，这是因为，数据发生变动时，还需要额外的开销更新索引。 文章目录 聚簇索引与非聚簇索引 MongoDB索引分类 主键索引 单字段索引 复合索引 复合索引与排序共用 唯一索引 复合唯一索引 去除重复 稀疏索引 TTL索引 全文索引 地理空间索引 索引优化 查询优化 写操作优化 聚簇索引与非聚簇索引 磁盘上的数据某一时刻只能有一种排序方式，而聚簇索引的特点是：索引顺序与数据存储顺序一致，所以聚簇索引只能有一个。 《数据库原理》中对聚簇索引的定义：聚簇索引的叶子节点是数据节点，非聚簇索引的叶子节点仍然是索引节点，只不过有指向对应数据块的指针。

1.性能下降SQL慢 执行时间长 等待时间长 查询语句写的烂 索引失效(单值，复合) 关联查询太多join(设计缺陷或不得已的需求) 服务器调优及各个参数设置(缓冲\线程数等) 2.常见通用的join查询 2.1SQL执行顺序 2.1.1手写 2.1.2机读 2.1.3总结 2.2Join图 2.3建表SQL 2.4 7种Join 3.索引简介 3.1什么是索引 MySQL官方对索引的定义为：索引(Index)是帮助MySQL高效获取数据的数据结构。 可以得到索引的本质： 索引是数据结构 可以简单理解为"排好序的快速查找数据结构"。 详解(重要): 结论： 数据本身之外,数据库还维护着一个满足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法,这种数据结构就是索引。 一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以文件形式存储在硬盘上. 我们平时所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉树)结构组织的索引。 其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然,除了B+树这种类型的索引之外，还有哈希索引(hash index)等。 3.2索引优势 类似大学图书馆建书目索引，提高数据检索效率，降低数据库的IO成本 通过索引列对数据进行排序

优化目标 减少 IO 次数 IO永远是数据库最容易瓶颈的地方，这是由数据库的职责所决定的，大部分数据库操作中超过90%的时间都是 IO 操作所占用的，减少 IO 次数是 SQL 优化中需要第一优先考虑，当然，也是收效最明显的优化手段。 降低 CPU 计算 除了 IO 瓶颈之外，SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户（这些操作基本上都是 CPU 处理内存中的数据比较运算）。当我们的 IO 优化做到一定阶段之后，降低 CPU 计算也就成为了我们 SQL 优化的重要目标 优化方法 改变 SQL 执行计划 明确了优化目标之后，我们需要确定达到我们目标的方法。对于 SQL 语句来说，达到上述2个目标的方法其实只有一个，那就是改变 SQL 的执行计划，让他尽量“少走弯路”，尽量通过各种“捷径”来找到我们需要的数据，以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标 常见误区 count(1)和count(primary_key) 优于 count(*) 很多人为了统计记录条数，就使用 count(1) 和 count(primary_key) 而不是 count(*) ，他们认为这样性能更好，其实这是一个误区。对于有些场景，这样做可能性能会更差，应为数据库对 count(*)

mysql 排序内容筛选 如果要筛选大于10的值做倒序，小于10的不做倒序排序的话 例： select * from database order by num>10 desc limit 0,10; 来源： CSDN 作者： xjie_127 链接： https://blog.csdn.net/xjie_127/article/details/103936266

sql 语句性能分析 1、看 sql 语句执行时间 2、看 sql 的执行计划 3、查看 sql 的执行中各个环节耗时时间 4、查看mysql的执行进程，处理锁表的情况，命令 show PROCESSLIST， state 为LOCKED，说明产生锁表，ID为进程id，直接执行kill ID，就可以停止这个进程； MySQL整个查询执行过程： 1、客户端同数据库服务层建立TCP连接。2、客户端向MySQL服务器发送一条查询请求。3、连接线程接收到SQL语句之后，将语句交给SQL语句解析模块进行语法分析和语义分析。4、先看查询缓存中是否有结果，如果有结果可以直接返回给客户端。5、如果查询缓存中没有结果，就需要真的查询数据库引擎层了，于是发给SQL优化器，进行查询的优化，生成相应的执行计划。6、MySQL根据执行计划，调用存储引擎的API来执行查询7、使用存储引擎查询时，先打开表，如果需要的话获取相应的锁。 查询缓存页中有没有相应的数据，如果有则可以直接返回，如果没有就要从磁盘上去读取。8、当在磁盘中找到相应的数据之后，则会加载到缓存中来，从而使得后面的查询更加高效，由于内存有限，多采用变通的LRU表来管理缓存页，保证缓存的都是经常访问的数据。9、最后，获取数据后返回给客户端，关闭连接，释放连接线程。 Procedure Analyse优化表结构 PROCEDURE ANALYSE()

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 正文： 一、先说说什么是索引？ 索引(index)翻译为一个目录，用于快速定位我们想要找的数据的位置。例如：我们把一个数据库比作一本书，而索引(index)就是书中的目录，此刻要找到书的某个感兴趣的内容，我们一般是不会整本书翻完再去确认该内容在哪里，而是通过书的目录，定位到该内容章节所在页数，最后直接翻到该页面 我们来看看在数据库中的索引： 全表扫描 VS 索引扫描 以字典为例，全表扫描就是如果我们查找某个字时，那么通读一遍新华字典，然后找到我们想要找到的字 而跟全表扫描相对应的就是索引查找，索引查找就是在表的索引部分找到我们想要找的数据具体位置，然后会到表里面将我们想要找的数据全部查出 实例：在一张学生表找到一个名字叫Dev的学生 左边全表扫描：需要从第一行开始一行行的扫描，直到找到100008行Dev这个学生的信息为止，将这个数据返回回来，但有可能该表中还有同名的学生，因此扫描并没有结束，通常全表扫描要找到一个数据，是需要将整张表的数据遍历一遍，然后才能确定是否将所有数据返回 右边索引扫描：索引查找是根据首字母排序找到D开头的Dev,如果首字母相同，那么再根据第二个字母排序找到，以此类推，我们找到ID为100008，然后回表查出ID为100008的数据 结论：因此索引(对应InnoDB

目录 1.什么是索引？为什么要用索引？ 1.1索引的含义 1.2为什么用？ 2.索引的作用与缺点 2.1作用 2.2缺点 3.索引的使用场景 3.1应创建索引的场景 3.2不应创建索引的场景 4.索引的分类与说明 4.1主键索引 4.2单列索引 4.3唯一索引 4.4复合索引 4.5聚集索引与非聚集索引 4.5.1聚集索引 4.5.2非聚集索引 4.5.3使用及语法 4.5.4使用场景对比 4.6聚簇索引与非聚簇索引 4.6.1聚簇索引 4.6.2非聚簇索引 4.6.3Mysql的MYISAM和INNODB引擎 4.6.4对比总结 4.7稠密索引与稀疏索引 4.7.1稠密索引 4.7.2稀疏索引 5.索引的底层原理 5.1 B-Tree 5.2 B+Tree 5.3 B-树和B+树的区别 6. 总结 1.什么是索引？为什么要用索引？ 1.1索引的含义 数据库索引,是数据库管理系统中一个排序的数据结构,以协助快速查询,更新数据库中表的数据.索引的实现通常使用B树和变种的B+树(mysql常用的索引就是B+树)。除了数据之外,数据库系统还维护为满足特定查找算法的数据结构,这些数据结构以某种方式引用数据.这种数据结构就是索引！ 简言之，索引就类似于书本，字典的目录！ 1.2为什么用？ 打个比方，如果正确合理设计并且使用索引的MySQL是一辆兰博基尼的话