mysql排序

正文： SELECT t.*, MAX(t.score) maxScore FROM (SELECT * FROM student ORDER BY score DESC LIMIT 1000) t GROUP BY t.student_id LIMIT 1000：MySQL分组查询时默认按照id从小到大的顺序排列会让自定义的排序，所以里面加上LIMIT 固定住排序。//TODO 待研究 参考博客： mysql分组后获取每个组排序后的第一条数据（整行） - persistence勿忘初心 - CSDN博客 https://blog.csdn.net/persistencegoing/article/details/92764058 来源： https://www.cnblogs.com/huashengweilong/p/11374875.html

目录 一, 什么是索引 二, 索引的数据结构 三, Mysql索引管理 四, 正确使用索引 五, 联合索引与覆盖索引 六, 补充 一, 什么是索引 为什么要有索引? 一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，在生产环境中，我们遇到最多的，也是最容易出问题的，还是一些复杂的查询操作，因此对查询语句的优化显然是重中之重。说起加速查询，就不得不提到索引了。 什么是索引？ 索引在MySQL中也叫是一种“键”，是 存储引擎用于快速找到记录的一种数据结构 。索引对于良好的性能非常关键，尤其是当表中的数据量越来越大时，索引对于性能的影响愈发重要。索引优化应该是对查询性能优化最有效的手段了。索引能够轻易将查询性能提高好几个数量级。索引相当于字典的音序表，如果要查某个字，如果不使用音序表，则需要从几百页中逐页去查。 有哪些索引? 索引种类 : memory(hash索引); (innodb/myisam)-b+tree(聚集索引 辅助索引) mysql中有哪些索引? primary key 主键索引\联合主键索引 unique key 唯一索引\联合唯一索引 index key 普通索引\联合索引 二, 索引的数据结构 本质是: 通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是说，有了这种索引机制

目录 数据库MySQL学习笔记高级篇 写在前面 1. mysql的架构介绍 mysql简介 mysqlLinux版的安装 mysql配置文件 mysql逻辑架构介绍 mysql存储引擎 2. 索引优化分析 性能下降SQL慢 常见通用的Join查询 索引简介 性能分析 索引优化 3. 查询截取分析 查询优化 慢查询日志 批量数据脚本 Show Profile 全局查询日志 4. MySQL锁机制 概述 三锁 5. 主从复制 复制的基本原理 复制的基本原则 复制的最大问题 一主一从常见配置 数据库MySQL学习笔记高级篇 写在前面 学习链接： 数据库 MySQL 视频教程全集 1. mysql的架构介绍 mysql简介 概述 高级Mysql 完整的mysql优化需要很深的功底，大公司甚至有专门的DBA写上述 mysql内核 sql优化工程师 mysql服务器的优化 各种参数常量设定 查询语句优化 主从复制 软硬件升级 容灾备份 sql编程 mysqlLinux版的安装 mysql5.5 下载地址：https://dev.mysql.com/downloads/mysql/5.5.html#downloads 检查当前系统是否安装过mysql： 查询命令：rpm -qa|grep -i mysql 删除命令：rpm -e RPM软件包名称 删除自带的mysql：yum -y remove

概念 如果索引 包含所有满足查询需要的数据的索引成为覆盖索引(Covering Index)，也就是平时所说的不需要回表操作 判断标准 使用explain，可以通过输出的extra列来判断，对于一个索引覆盖查询，显示为 using index ,MySQL查询优化器在执行查询前会决定是否有索引覆盖查询 注意 1、覆盖索引也并不适用于任意的索引类型，索引必须存储列的值 2、Hash 和full-text索引不存储值，因此MySQL只能使用B-TREE 3、并且不同的存储引擎实现覆盖索引都是不同的 4、并不是所有的存储引擎都支持它们 5、如果要使用覆盖索引，一定要注意SELECT 列表值取出需要的列，不可以是SELECT *，因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降，不能为了利用覆盖索引而这么做 InnoDB 1、覆盖索引查询时除了除了索引本身的包含的列，还可以使用其默认的 聚集索引列 2、 这跟INNOB的索引结构有关系，主索引是B+树索引存储，也即我们所说的数据行即索引，索引即数据 3、对于INNODB的辅助索引，它的叶子节点存储的是索引值和指向主键索引的位置，然后需要通过主键在查询表的字段值，所以辅助索引存储了主键的值 4、覆盖索引也可以用上INNODB 默认的聚集索引 5、 innodb引擎的所有储存了主键ID，事务ID，回滚指针,非主键ID

在某些情况中， MySQL 可以使用一个索引来满足 ORDER BY 子句，而不需要额外的排序。 即使 ORDER BY 不确切匹配索引，只要 WHERE 子句中的所有未使用的索引部分和所有额外的 ORDER BY 列为常数，就可以使用索引。下面的查询使用索引来解决 ORDER BY 部分： 注： key_part1 , key_part2为建立了索引的列 SELECT * FROM t1 ORDER BY key_part1 , key_part2 ,... ; SELECT * FROM t1 WHERE key_part1 = constant ORDER BY key_part2 ; SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC; SELECT * FROM t1 WHERE key_part1 =1 ORDER BY key_part1 DESC, key_part2 DESC; 在某些情况下， MySQL 不能 使用索引来解决 ORDER BY ，尽管它仍然使用索引来找到匹配 WHERE 子句的行。这些情况包括： · 对不同的关键字使用 ORDER BY ： · SELECT * FROM t1 ORDER BY key1, key2； · 对关键字的非连续元素使用 ORDER BY ： ·

MySQL 按照数据库表字段动态排序 查询列表信息 背景描述 项目中数据列表分页展示的时候，前端使用的Table组件，每列自带对 当前页 的数据进行 升序 或者 降序 的排序。 但是客户期望点击每列的时候，对查询到的所有数据进行排序。 举例说明： 查询到的有100条数据，每页10条，共10页。前端Table组件，可以对当前页的10条数据，进行排序，其他的9页并不参与排序。 但是，实际期望是对查询到的10页数据均参与排序。并且不是特定列，而是每列均可以按照升序或者降序，将查询到的结果进行再次排序。 处理方式 由于前端技术的限制，需要在后端进行处理，对查询列表的接口进行修改。 1、修改查询实体类 首先需要在查询条件的请求实体中，增加两个字段 orderField 和 orderType ，用于保存传入字段名和排序的方式（升序ASC，降序DESC） orderField：用于接收需要排序的字段 orderType：用于接收排序的方式，ASC，DESC，asc，desc 代码如下： // 对字段进行排序 private String orderField; // 存放排序字段 private String orderType; // ASC DESC public String getOrderField() { return orderField; } public void

前言 排序是数据库中的一个基本功能，MySQL也不例外。用户通过Order by语句即能达到将指定的结果集排序的目的，其实不仅仅是Order by语句，Group by语句，Distinct语句都会隐含使用排序。本文首先会简单介绍SQL如何利用索引避免排序代价，然后会介绍MySQL实现排序的内部原理，并介绍与排序相关的参数，最后会给出几个“奇怪”排序例子，来谈谈排序一致性问题，并说明产生现象的本质原因。 1.排序优化与索引使用 为了优化SQL语句的排序性能，最好的情况是避免排序，合理利用索引是一个不错的方法。因为索引本身也是有序的，如果在需要排序的字段上面建立了合适的索引，那么就可以跳过排序的过程，提高SQL的查询速度。下面我通过一些典型的SQL来说明哪些SQL可以利用索引减少排序，哪些SQL不能。 假设t1表存在索引key1(key_part1,key_part2),key2(key2) a.可以利用索引避免排序的SQL SELECT * FROM t1 ORDER BY key_part1,key_part2; SELECT * FROM t1 WHERE key_part1 = constant ORDER BY key_part2; SELECT * FROM t1 WHERE key_part1 > constant ORDER BY key_part1 ASC;

mongodb利用索引对find结果排序(sort) 最近线上有个接口超时报警，排查发现是查询MongoDB的时候比较慢（平均耗时1s以上）。文档结构很简单： { "_id" : NumberLong(1214789), "created_at" : ISODate("2019-02-21T16:08:44.337Z"), "updated_at" : ISODate("2019-02-21T16:08:44.337Z"), "cid" : 158865, "uid" : NumberLong(1024654707), "object_id" : "", "random" : 163595854, "participation_num" : 1 } 已有索引： {"_id":1} {"uid":1} {"cid":1} {"cid":1,"uid":1} 接口里的查询转换成查询语句为： db.record.find({ "cid":158865, "is_del": { "$ne": true } }).sort({"_id": -1}).limit(10) 数据量100W+，不小，但是对MongoDB来说应该也不算大。 想当然的觉得：已经有cid索引，那么find时走索引应该查起来很快，排序的话，_id也是有索引的，应该不会出现问题啊。后经老大指点

索引 为社么要使用索引 避免全表扫描，快速查询数据 数据库中有什么信息可以成为索引 主键、唯一键及普通键等 索引的数据结构 生成索引，建立二叉查找树进行二分查找 生成索引，建立B-Tree结构进行查找 生成索引，按照B+-Tree结构进行查找 Mysql索引 生成索引，按照Hash结构进行查找 普通的二叉查找树会被深度限制搜索速度，深度增加1，就多进行一次IO。 B+Tree，Hash，BitMap MySQL不支持BitMap，且支持InnoDB和MYISAM的 MySQL不显式支持Hash B-Tree ​ 根节点至少包含两个孩子，根节点的孩子数为m ​ 树中每个节点最多含有m个孩子（m大于等于2） ​ 除了根节点和叶子节点外，其他每个节点至少含有ceil个节点（m/2向上取整） ​ 所有叶子节点都位于同一层 ​ 假设每个非终端节点中包含n个关键字信息，其中： ​ a： Ki 为关键字，关键字按升序排列，Ki<K（i-1） ​ b: 关键字个数n，：ceil<=n<=m-1 ​ c: 非叶子节点的指针：p[1],p[2],….p[m],其中p[1]指向关键字小于K[1]的子树，p[m]指向关键字大于K[m-1]的子树，其他p[i],指向关键字属于（K[i-1],K[i]）的子树 B+ Tree 非叶子节点的子树指针与关键字个数相同 非叶子节点的子树指针P[i],

mysql查询、子查询、连接查询 一、mysql查询的五种子句 where子句（条件查询）：按照“条件表达式”指定的条件进行查询。 group by子句（分组）：按照“属性名”指定的字段进行分组。group by子句通常和count()、sum()等聚合函数一起使用。 having子句（筛选）：有group by才能having子句，只有满足“条件表达式”中指定的条件的才能够输出。 order by子句（排序）：按照“属性名”指定的字段进行排序。排序方式由“asc”和“desc”两个参数指出，默认是按照“asc”来排序，即升序。 limit（限制结果集）。 1、where——基础查询 where常用运算符： 2、group by 分组 “Group By”从字面意义上理解就是根据“By”指定的规则对数据进行分组，所谓的分组就是将一个“数据集”划分成若干个“小区域”，然后针对若干个“小区域”进行数据处理。 select 类别, sum(数量) as 数量之和 from A group by 类别 注：group by语句中select指定的字段必须是“分组依据字段”，其他字段若想出现在select中则必须包含在聚合函数中。 mysql中五种常用的聚合函数： （1）max(列名)：求最大值。 （2）min(列名)：求最小值。 （2）sum(列名)：求和。 （4）avg(列名)：求平均值