读高性能Mysql--Mysql优化

一、思路概述

设计表时优化：

1.数据类型优化--更小的通常更好，占用更少的磁盘，内存cpu，并且处理时需要的cpu周期更少，但不要爆了。

2.整数类型优化--比如int占32位储存空间，储存范围-2^（32-1）到2^（32-1）-1，使用unsigned，可以把范围编程0~2^(32)-1(翻倍)

3.尽量避免用null，对mysql更难优化，因为null的列使得索引，索引统计，和值比较都更加复杂，可以为null的列会占用更多的储存空间；把可为null的字段改为not null对性能提升比较小，一般建表的时候可以考虑

4.设计表的时候，很少用到的字段就别设了，服务器层和储存引擎通过行缓冲格式拷贝数据，然后服务器层将缓冲内容解码成各个列，如果太宽，转换代价高

5.范式和反范式：范式化的更新通常比反范式快；范式化表通常小，储存小，所以执行快；但是范式化缺点是通常需要关联，而且可能把列储存在不同表中，使得原本在同一个表中的索引失效。

 -------------------------------------------------------------------------------------------------------------------------------

mysql底层知识：

1.客户端连接都在服务端有线程，服务器会缓存残存线程，因此不需要眉心间一个连接创建销毁线程。

2.并发控制：通过锁来阻止两个进程同时操作一个数据，但缺点是，任意一个时刻只能有一个进程可以操作数据。

3.mysql会在某个进程修改数据的时候锁定，防止其他用户读和写。

4.共享锁和排它锁 也叫 读锁和写锁。（读锁互补阻塞，写锁阻塞所有）。

5.只要互相不发生冲突，锁越少，并发程度越高（越高效）。

6.死锁，指多个事务在同一资源上相互占用，并请求锁定对方占用的资源（多个事务，意思是可以同时执行同一句，使之锁定）

 7.索引储存在引擎层而不是服务器层实现，不同的储存引擎的索引的工作方式不一样。

8.索引在没有特别指明类型多半指B-Tree索引，使用B-Tree数据结构储存内存。--key1--key2--，然后下面分小于key1，在key1key2中间，大于key2；B-Tree的值key，是按顺序储存的。

 （B-Tree链接：https://blog.csdn.net/ifollowrivers/article/details/73614549）

9.索引的优点：减少服务器需要扫描的数据量，帮助服务器避免排序和临时表，将随机I/O,变为顺序I/O

10.索引的缺点：少数据全表扫描更有效率，增删多，索引会增加消耗。

 

（查询的知识）

11.查询的生命周期：从客户端，到服务器，然后在服务器上进行解析，生成执行计划，执行，然后返回结果给客户端。其中“执行”包括大量检索数据，引擎的调用以及调用后的数据处理，包括排序，分组。

12.查询需要花费的时间：网络，cpu计算，生成统计信息和执行计划，锁等待，特别是底层储存引擎检索数据的调用操作。

13.优化在于解决，一些不必要的额外操作，某些操作额外重复了很多次，某些操作太慢等。

14.查询执行的基础

　　14.1客户端发送一条查询给服务器。

　　14.2.务器检查魂村，如果命中缓存，立刻返回储存中的缓存结果，否则继续。

　　14.3.服务器端进入sql解析，预处理，再优化生成对应的执行计划。

　　14.4.Mysql根据优化器生成的执行计划，条用储存引擎的api来执行查询

　　　　

-------------------------------------------------------------------------------------------------------------------------------

查询性能优化

1.慢查询基础，减少访问量（程序是否检索大量超过需要的数据，mysql服务器层是否在分析大量超过需要的数据行）（慢日志，慢日志会把sql响应时间，扫面行数，返回函数记录，检查慢日志有助于我们分析优化；响应时间--服务时间+等待时间，服务时间是这个查询真正用的时间，等待时间有关于锁、高并发资源竞争，硬件响应都会影响响应时间，通过“快速上限估计”法来判断响应时间是否是合理值；快速上限估计--了解这个查询需要哪些索引以及他的执行计划是什么，大概需要多少个顺序和随机I/O，再用其乘以具体硬件条件下一次I/O的消耗时间，最后把消耗加起来，百度吧；扫描行数==返回行数--很理想，一把1比1或10比1之间）

　　1.1避免查询不需要记录--善用limit，而不是查询所有数据，然后后台再取需要的。

　　 1 SELECT * FROM tbl_emp LIMIT 5 

　　1.2重复查询相同的数据--善用缓存：用户评论的时候，我们需要查询到他的头像的url，如果用户多次评论，我们是不是要不断的查询呢，这时候我们只要把这个数据缓存起来，

　　需要的时候再取出来，性能更好。

　　1.3发现查询需要扫描大量的行，但返回很少数据--①使用索引覆盖扫描，②改写库表结构，使用单独的汇总表（百度）③重写这个查询

2.重构查询的方式

　　2.1.切分查询--当需要执行一个数据量很大的操作时，分批执行

　　2.2.分解关联查询（分解技巧百度）--让缓存效率更高，减少锁的竞争，数据库拆分，更容易做到高性能可拓展，减少冗余的查询，相当于实现了哈希关联（哈希关联百度）

3.优化特定类型的查询

　　3.1.优化count（）查询：count（）括号里可以统计某列值的行数，如果是*代表直接返回总行数，不会拓展成所有列。

　　　　　比如我们要查询所有ID>5的城市，如果id值非常大，查询ID < 5 再总数减去会快很多。