mysql有很多处理机制,很多线程,比如对用户发起的链接进行身份验证authentication,
限制最大连接数connection limit,
检查内存 check memory,
管理缓存caches,
线程重用thread reuse(线程在前面用户用完,不会销毁,会把用户的私有信息清理干净,再放到空闲线程中,供下一个来使用)
sqlinterface (检查用户执行的sql语句是否正确,如果正确,进入到parser解释器,sql转换,翻译成二进制指令,
其中设计到对象特权,权限是否可以执行进行检查)
在执行的时候还需要进行优化OPTIMIZER,可能在执行的时候有多种方式去实现,access paths 访问路径,
选择一条最优路线来执行,这个过程可以通过执行计划来看到
执行完后,用户就可以看到返回的客户端了
cache缓存 buffer缓冲,一般cache读,buffer负责写
读数据,数据先放到caches里
写数据,写的数据写放到buffer再写到磁盘上(没有buffer就是改一次写一次,有了buffer可以把多次写,先放到buffer,然后批量写到磁盘,可能有数据丢失的风险)
pluggable storage engines要把数据写到磁盘上就需要借助存储引擎,写到磁盘就需要和内核打交道,否则对文件系统没权限
用户发指令给数据库里的查询过程是如何实现的
用户在连接数据库后,查询东西,数据库不是马上去执行,而是查看查询缓存(缓存了以前先执行的sql语句内容)
但是有个要求,就是sql指令跟上次查询的时候,sql语句大小都一样,差一个字母都不行,因为使用哈希值比较的
程序员写代码规范就比较重要
(缓存如果命中就直接返回结果)
如果查询缓存没有的话,就需要发到解析器,这个解析器负责把指令转换成2进制,还需要查看是否有访问权限,
接下来是解析树,就是要得到数据,有多种路径,预处理器,选择最优路径,有可能还需要进一步修改语句的写法
修改他经过优化之后,进而去执行,执行计划,发送到存储引擎,进而得到数据,返回用户的同时放到查询缓存
如何启用查询缓存
为何要严格大小写,是因为查询缓存命中就是用的哈希hash算法,hash对数值进行hash,得到一个摘要值digest,摘要值多长就用hash算法,摘要值是定长的,算法不可逆推原来的值
数据不变摘要值不变
缓存命中需要判断hash的,所以增加了使用门槛,降低了效率查询缓存也会增加系统的负载,不是所有的命令都适合缓存的
now()直接返回系统时间,这个就没必要缓存
sql_no_cache,如果加这个选项的化,sql语句就不会被缓存了,如果想要看一个大表,几十兆。就不要缓存,增加负担把这个关键字一加就成临时表了
临时表一般都是临时处理数据的,用完就会自动删除
缓存相关的变量
缓存的最小分配单位,物理上在磁盘分配的最小单位是block块,较小的值可以减少浪费
多大就无法缓存了,既然缓存不了,就建议加sql_no_cache
整个查询缓存的可用的内存空间
不能这么设置
可以不加单位,重启服务就丢了,是临时的查看是否是服务器选项,服务器选项才能写入配置文件
是选项也是变量
写100M试试
多个用户访问数据库,有可能一个在修改表,事务还没改完的数据叫脏数据,默认off,别人改数据,别人仍然能从缓存里访问
如何直到缓存有效
有和查询缓存相关的状态变量
剩下的空闲块
总的空闲内存
向缓存区中添加新的缓存次数(意味这个select是新的)
缓存放不下,也会淘汰,LRU最近最少使用算法
访问次数越多,始终就是优先访问的
无法被缓存的sql语句
虽然没有结果也会把没有结果的信息缓存下来
不关心结果,只是关心的你的命令是否一样
命中率就是命中次数/总次数
加了空格就认为是不同 语句了
换大小写也是不命中的
(缓存总大小-剩余空间)/缓存中的记录数
利用索引大大改善磁盘读写性能,本身是个特殊的数据解构,在mysql叫key,键
索引的实现不是依赖于存储引擎的,而是数据库自身决定的,它的索引技术是差别很大的
能够花两次读取磁盘数据,就不要用10次,因为磁盘的速度是比较慢的
在磁盘上找数据,以前没有索引到处找,全表扫描,有了索引以后可以将数据按照一定的次序排序,排序完以后,可以快速的定位
索引本身缺点就是也要占用空间,有可能就会影响添加数据的速度,如果是写多读少,就可以考虑不加索引了
索引种类
B树索引
二叉树和B树有比较大的区别,二叉树最多两个分支,二叉树带来的问题是树的高度可能比较高,根节点,分支结点,叶子结点,最坏的结果是把所有的结点都找一遍才能找到,
平衡树就不一样,B-TREE,高度比二叉树矮很多,同样的数据放到二叉树可能分层的更多,放到B树里就矮胖,IO次数变少,查数据就方便,也是按照数据从小到大,每个索引页数均匀存放的,元素是三个,分支就是三个。
平衡树的缺点是每次查询效率可能并不一致,比如查17号,就一下子查到了,查28号就要到最下面才能查到
mysql用的索引是B+TREE索引,B+树索引,b=balance 平衡,根节点和分支节点不放数据,只放索引
下面的叶子结点放数据
由于上面的根节点和分支结点只放索引,所以更加矮胖,重要的是,B+树还支持指针,相邻都有指针,带来的优势就是,找9号到30号,可以通过这个指针直接就找了,不用从跟部开始重新找,提高了速度
用的最多的是B+tree
可以基于地理位置的搜索
B+树的例子
B+树的特性,每个节点到根节点的距离是相同的,上面跟节点和分支结点本身不放数据只放索引,所有数据都在叶子节点,叶子节点距离跟的位置都是一致的,所以每次查询效率都是稳定的
sql语句写的不行。意味着B+树的特性无法用到