mysql排序

索引 当MySQL单表记录数过大时，增删改查性能都会急剧下降。MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度。一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的，而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量。 索引优势和劣势： 优势： 大大减少了服务器需要扫描的数据量，可以帮助服务器避免排序和临时表，实现快速检索，将随机I/O变成顺序I/O，减少I/O次数，加快检索速度；根据索引分组和排序，可以加快分组和排序； 劣势： 索引本身也是表，因此会占用存储空间，一般来说，索引表占用的空间的数据表的1.5倍；索引表的维护和创建需要时间成本，这个成本随着数据量增大而增大；构建索引会降低数据表的修改操作（删除，添加，修改）的效率，因为在修改数据表的同时还需要修改索引表；创建索引时需要对表加锁，因此实际操作中需要在业务空闲期间进行。 索引类型 Mysql目前主要有以下几种索引类型：FULLTEXT，HASH，BTREE，RTREE。 FULLTEXT 即为全文索引，目前只有MyISAM引擎支持。其可以在CREATE TABLE ，ALTER TABLE ，CREATE INDEX 使用

分组的SQL语句有2个： group by 和分组聚合函数实现 partition by （oracle和postgreSQL中的语句）功能 group by + having 组合赛选数据 注意：having 条件的字段必须在前面查询赛选存在，否则语法错误 错误格式： SELECT MAX(ID),U_ID FROM mlzm_comments GROUP BY U_ID HAVING Data_Status >0 正确格式： SELECT MAX(ID),U_ID,Data_Status FROM mlzm_comments GROUP BY U_ID HAVING Data_Status >0 group by强调的是一个整体，就是组，只能显示一个组里满足聚合函数的一条记录， partition by 在整体后更强调个体，能显示组里所有个体的记录。 #实际需求，获取满足条件第一条信息或最后一条信息 步骤拆解： #步骤一：找出所有符合第一条件条件的数据,默认排序是按主键索引升序排列,这里按u_id 字段排序方便审阅 SELECT a.ID,a.U_ID FROM mlzm_content a WHERE a.Data_Status = 2 ORDER BY a.U_ID,a.ID ASC; #步骤2：利用group by 和max()、min()函数

utf8 与 utf8mb4 标准的 UTF-8 字符集编码是可以用 1~4 个字节去编码21位字符，是一种变长的编码格式，这几乎包含了是世界上所有能看见的语言了。然而在MySQL里实现的utf8最长使用3个字节，节省空间但不能表达全部的UTF-8，只支持到了 Unicode 中的“基本多文种平面”（U+0000至U+FFFF，Basic Multilingual Plane，BMP），包含了控制符、拉丁文，中、日、韩等绝大多数国际字符，但并不是所有，最常见的就算现在手机端常用的表情字符 emoji和一些不常用的汉字，如 “墅” ，这些需要四个字节才能编码出来。 MySQL在 5.5.3 之后增加了 utf8mb4 字符编码，mb4即 most bytes 4,使用4个字节来表示完整的UTF-8。简单说 utf8mb4 是 utf8 的超集并完全兼容utf8，能够用四个字节存储更多的字符。 注：QQ里面的内置的表情不算，它是通过特殊映射到的一个gif图片。一般输入法自带的就是。 当你的数据库里要求能够存入这些表情或宽字符时，可以把字段定义为 utf8mb4，同时要注意连接字符集也要设置为utf8mb4，否则在 严格模式 下会出现 Incorrect string value: /xF0/xA1/x8B/xBE/xE5/xA2… for column 'name'这样的错误

【问题现象】 线上mysql数据库爆出一个慢查询，DBA观察发现，查询时服务器IO飙升，IO占用率达到100%， 执行时间长达7s左右。 SQL语句如下： SELECT DISTINCT g.*, cp.name AS cp_name, c.name AS category_name, t.name AS type_name FROMgm_game g LEFT JOIN gm_cp cp ON cp.id = g.cp_id AND cp.deleted = 0 LEFT JOIN gm_category c ON c.id = g.category_id AND c.deleted = 0 LEFT JOIN gm_type t ON t.id = g.type_id AND t.deleted = 0 WHERE g.deleted = 0 ORDER BY g.modify_time DESC LIMIT 20 ; 【问题分析】 使用explain查看执行计划，结果如下： 这条sql语句的问题其实还是比较明显的： 查询了大量数据(包括数据条数、以及g.* )，然后使用临时表order by，但最终又只返回了20条数据。 DBA观察到的IO高，是因为sql语句生成了一个巨大的临时表，内存放不下，于是全部拷贝到磁盘，导致IO飙升。 【优化方案】 优化的总体思路是拆分sql，

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

Mysql学习笔记（2） https://blog.csdn.net/Fhujinwu/article/details/81517266 DML操作时指对数据库中表记录的操作，主要包括表记录的插入（insert）、更新（update）、删除（delete）和查询（select），是开发人员日常使用最频繁的操作。 1、①插入记录的语法如下：insert into tablename(表名)(field1,field2,...,fieldn) valuse(value1,value2,...,valuen); 例如向表emp中插入以下记录：ename为zzx1，hiredata为2018-08-08 sal为2000，deptno为1，执行 为insert into emp(ename,hiredata,sal,deptno) values('zzx1','2018-08-08','3000',1); ②查看实际插入的值：select*from tablename 比如select*from emp； ③连续插入多条记录的语法如下： INSERT INTO tablename (field1, field2, …, fieldn) VALUES (record1_value1, record1_value2, …, record1_valuesn), (record2_value1,

背景：sql 优化对数据来说是什么非常重要，sql的索引优化更重中之重，有的人认为索引优化就是简单加一个索引，其实这种想法是错的，索引是涉及到很多知识点，并非大家想得这么简单，废话不多说，马上开车！ 一，头盘： SQL语句的五大要素： 1，获得结果集所需访问的查询条件 2，定义结果集所需的查询条件 3，结果集的大小 4，获得结果集所涉及的表的数量 5，多少用户同时修改这些数据 二，主菜：索引的一些特性和优化建议 1，经常变的索引列放在最后，这样会降低变更成本 2，索引字段的顺序非常重要，如果排序前有范围查询就不能使用索引排序，如： 索引A(a,b.c) select a,b,c from t where a=1 and b between d1 and d2 order by c; 这样就需要排序 索引B(a,c,b) 就不用排序 --备注： 一般来说会优先选择B不需要排序，因为一般来说一个事务每次查询的结果集都是很小的，会限定输出的结果集，这个时候不用排序就会很快，选择索引A时结果集要排序，如果结果集(满足条件的结果)很大的话，这样是会很慢的 3，当以下三个条件同时满足，过虑因子隐患可以会产生： 1)，访问路径中没有排序 2)，第一屏幕结果一建立就回应 3)，不是所有的谓词字段都参与定义待扫描的索引片 4，使用短索引。如果对多列进行索引，应该指定一个前缀长度