MySQL 基本知识点梳理和查询优化.docx

《MySQL 基本知识点梳理和查询优化.docx》由会员分享，可在线阅读，更多相关《MySQL 基本知识点梳理和查询优化.docx（12页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、MySQL基本知识点梳理和查询优化陈芳志;：说明MySQL会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成的排序操作称为“文件排序，其实不一定是文件排序，内部使用的是快排2、usingtemporary：使用了临时表保存中间结果，MySQL在对查询结果排序时使用临时表。常见于排序orderby和分组查询groupby3、usingindex：表示相应的SELECT操作中使用了覆盖索引（CoveringIndex），避免访问了表的数据行，效率不错。4、impossiblewhere：WHERE子句的值总是false，不能用来获取任何元组5、selec

2、ttablesoptimizedaway：在没有GROUPBY子句的情况下基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化6、distinct：优化distinct操作，在找到第一匹配的元祖后即停止找同样值的操作usingfilesort,usingtemporary这两项出现时需要注意下，这两项是十分耗费性能的，在使用groupby的时候，虽然没有使用orderby，如果没有索引，是可能同时出现usingfilesort,usingtemporary的，因为groupby就是先排序在分组，如果没有

3、排序的需要，可以加上一个orderbyNULL来避免排序，这样usingfilesort就会去除，能提升一点性能。type字段system：表只有一行记录（等于系统表），这是const类型的特例，平时不会出现const：如果通过索引依次就找到了，const用于比较主键索引或者unique索引。因为只能匹配一行数据，所以很快。如果将主键置于where列表中，MySQL就能将该查询转换为一个常量eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描ref：非唯一性索引扫描，返回匹配某个单独值的所有行。本质上也是一种索引访问，它返回所有匹配某个单独值的行，然

4、而它可能会找到多个符合条件的行，所以它应该属于查找和扫描的混合体range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引，一般就是在你的where语句中出现between、<、>、in等的查询，这种范围扫描索引比全表扫描要好，因为只需要开始于缩印的某一点，而结束于另一点，不用扫描全部索引index：FullIndexScan，index与ALL的区别为index类型只遍历索引树，这通常比ALL快，因为索引文件通常比数据文件小。（也就是说虽然ALL和index都是读全表，但index是从索引中读取的，而ALL是从硬盘读取的）all：FullTableScan，

5、遍历全表获得匹配的行三、字段类型和编码1、mysql返回字符串长度：CHARACTER_LENGTH方法(CHAR_LENGTH一样的)返回的是字符数，LENGTH函数返回的是字节数，一个汉字三个字节2、varvhar等字段建立索引长度计算语句：selectcount(distinctleft(test,5)/count(*)fromtable;越趋近1越好3、mysql的utf8最大是3个字节不支持emoji表情符号，必须只用utf8mb4。需要在mysql配置文件中配置客户端字符集为utf8mb4。jdbc的连接串不支持配置characterEncoding=utf8mb4，最好的办法是在

6、连接池中指定初始化sql，例如：hikari连接池，其他连接池类似spring.datasource.hikari.connection-init-sql=setnamesutf8mb4。否则需要每次执行sql前都先执行setnamesutf8mb4。4、msyql排序规则(一般使用_bin和_genera_ci)：utf8_genera_ci不区分大小写，ci为caseinsensitive的缩写，即大小写不敏感，utf8_general_cs区分大小写，cs为casesensitive的缩写，即大小写敏感，但是目前MySQL版本中已经不支持类似于*_genera_cs的排序规则，直接使用u

7、tf8_bin替代。utf8_bin将字符串中的每一个字符用二进制数据存储，区分大小写。那么，同样是区分大小写，utf8_general_cs和utf8_bin有什么区别？cs为casesensitive的缩写，即大小写敏感；bin的意思是二进制，也就是二进制编码比较。utf8_general_cs排序规则下，即便是区分了大小写，但是某些西欧的字符和拉丁字符是不区分的，比如=a，但是有时并不需要=a，所以才有utf8_binutf8_bin的特点在于使用字符的二进制的编码进行运算，任何不同的二进制编码都是不同的，因此在utf8_bin排序规则下：<>a5、sqlyog中初始连接指定

8、编码类型使用连接配置的初始化命令四、SQL语句总结常用的但容易忘的：1、如果有主键或者唯一键冲突则不插入：insertignoreinto2、如果有主键或者唯一键冲突则更新,注意这个会影响自增的增量：INSERTINTOroom_remarks(room_id,room_remarks)VALUE(1,sdf)ONDUPLICATEKEYUPDATEroom_remarks=2343、如果有就用新的替代，values如果不包含自增列，自增列的值会变化：REPLACEINTOroom_remarks(room_id,room_remarks)VALUE(1,sdf)4、备份表：CREATETAB

9、LEuser_infoSELECT*FROMuser_info5、复制表结构：CREATETABLEuser_v2LIKEuser6、从查询语句中导入：INSERTINTOuser_v2SELECT*FROMuser或者INSERTINTOuser_v2(id,num)SELECTid,numFROMuser7、连表更新：UPDATEusera,roombSETa.num=a.num+1WHEREa.room_id=b.id8、连表删除：DELETEuserFROMuser,blackWHEREuser.id=black.id锁相关(作为了解，很少用)1、共享锁：selectidfromtb_

10、testwhereid=1lockinsharemode;2、排它锁：selectidfromtb_testwhereid=1forupdate优化时用到：1、强制使用某个索引：select*fromtableforceindex(idx_user)limit2;2、禁止使用某个索引：select*fromtableignoreindex(idx_user)limit2;3、禁用缓存(在测试时去除缓存的影响)：selectSQL_NO_CACHEfromtablelimit2;查看状态1、查看字符集SHOWVARIABLESLIKEcharacter_set%;2、查看排序规则SHOWVARI

11、ABLESLIKEcollation%;SQL编写注意1、where语句的解析顺序是从右到左，条件尽量放where不要放having2、采用延迟关联(deferredjoin)技术优化超多分页场景，比如limit10000,10,延迟关联可以避免回表3、distinct语句非常损耗性能，可以通过groupby来优化4、连表尽量不要超过三个表五、踩坑1、如果有自增列，truncate语句会把自增列的基数重置为0，有些场景用自增列作为业务上的id需要十分重视2、聚合函数会自动滤空，比如a列的类型是int且全部是NULL，则SUM(a)返回的是NULL而不是03、mysql判断null相等不能用“a

12、=null,这个结果永远为UnKnown，where和having中,UnKnown永远被视为false，check约束中，UnKnown就会视为true来处理。所以要用“aisnull处理六、千万大表在线修改mysql在表数据量很大的时候，如果修改表结构会导致锁表，业务请求被阻塞。mysql在5.6之后引入了在线更新，但是在某些情况下还是会锁表，所以一般都采用pt工具(PerconaToolkit)。另外搜索公众号后端架构师回复关键字架构整洁获取一份惊喜礼包。如对表添加索引：如下：pt-online-schema-change-user=root-host=localhost-ask-pas

13、s-alteraddindexidx_user_id(room_id,create_time)D=fission_show_room_v2,t=room_favorite_info-execute七、慢查询日志有时候如果线上请求超时，应该去关注下慢查询日志，慢查询的分析很简单，先找到慢查询日志文件的位置，然后利用mysqldumpslow去分析。查询慢查询日志信息可以直接通过执行sql命令查看相关变量，常用的sql如下：-查看慢查询配置-slow_query_log慢查询日志是否开启-slow_query_log_file的值是记录的慢查询日志到文件中-long_query_time指定了慢查

14、询的阈值-log_queries_not_using_indexes是否记录所有没有利用索引的查询SHOWVARIABLESLIKE%quer%;-查看慢查询是日志还是表的形式SHOWVARIABLESLIKElog_output-查看慢查询的数量mysqldumpslow的工具十分简单，我主要用到的是参数如下：-t:限制输出的行数，我一般取前十条就够了-s:根据什么来排序默认是平均查询时间at，我还经常用到c查询次数，因为查询次数很频繁但是时间不高也是有必要优化的，还有t查询时间，查看那个语句特别卡。-v:输出详细信息例子：mysqldumpslow-v-st-t10mysql_slow.l

15、og.2018-11-20-0500八、查看sql进程和杀死进程如果你执行了一个sql的操作，但是迟迟没有返回，你可以通过查询进程列表看看他的实际执行状况，如果该sql十分耗时，为了避免影响线上可以用kill命令杀死进程，通过查看进程列表也能直观的看下当前sql的执行状态，如果当前数据库负载很高，在进程列表可能会出现，大量的进程夯住，执行时间很长。命令如下：-查看进程列表SHOWPROCESSLIST;-杀死某个进程kill183665如果你使用的sqlyog，那么也有图形化的页面，在菜单栏-工具-显示-进程列表。在进程列表页面可以右键杀死进程。如下所示：九、一些数据库性能的思考在对公司慢查询

16、日志做优化的时候，很多时候可能是忘了建索引，像这种问题很容易解决，加个索引就行了。但是有两种情况就不是简单能加索引能解决了：1、业务代码循环读数据库：考虑这样一个场景，获取用户粉丝列表信息加入分页是十个其实像这样的sql是十分简单的，通过连表查询性能也很高，但是有时候，很多开发采用了取出一串id，然后循环读每个id的信息，这样如果id很多对数据库的压力是很大的，而且性能也很低2、统计sql：很多时候，业务上都会有排行榜这种，发现公司有很多地方直接采用数据库做计算，在对一些大表的做聚合运算的时候，经常超过五秒，这些sql一般很长而且很难优化，像这种场景，如果业务允许（比如一致性要求不高或者是隔一段时间才统计的），可以专门在从库里面做统计。另外我建议还是采用redis缓存来处理这种业务3、超大分页：在慢查询日志中发现了一些超大分页的慢查询如limit40000,1000，因为mysql的分页是在server层做的，可以采用延迟关联在减少回表。但是看了相关的业务代码正常的业务逻辑是不会出现这样的请求的，所以很有可能是有恶意用户在刷接口，所以最好在开发的时候也对接口加上校验拦截这些恶意请求。这篇文章就总结到这里，希望能够对你有所帮助！