数据库索引及树形结构简介（三）mysql优化

前言

1.在mysql当中，他的执行顺序是创建client---->server---->索引引擎
2.在server当中，sql本质上是一个字符串，在这里会对他进行关键字切割分析，之后将进行优化，mysql其实是自带优化的，分为RBO和CBO，然后其执行器与引擎在进行交互，从磁盘当中拉取数据，
3.IO时，在到多数应用场景当中，都应该避免频繁的IO的量和次数。
4.mysql的查询缓存，在8.0之后被删除了，其实对于数据来说，大多数都是需要频繁的插入和修改，所以缓存的命中不高，保证不了数据的实时性，那么将会失去缓存的意义

• 性能监控
  1.show profile （type）查询分析（自行百度）
  分析其sql的在server当中每一步的执行时间，从而判断问题所在
  常用的语句有：

show profile cpu  #查看使用内存
show profiles  #查看最近sql的执行时间
show profile all #显示所有时间
show profile block io #显示块io操作次数
show profile IPC #显示发送和接收的数量

但是可能在未来的版本可能会被移除掉

2.performance schema 用于监控mysql的运行性能，相比于show profile，使用他更容易监控mysql，特别是DBA来说用的会比较多，但要花很多时间去熟悉，可以自开发一个性能监控系统，用来监控你的数据库性能，（但是表太多了，官网看得吃力）

3.show processlist #查看连接的线程个数

常用的数据库连接池有（druid，hikari，tomcat-jdbc）

需要选择合适的连接池，一般情况下不会用到processlist

• schema与数据类型的优化
  1.数据类型的优化

• 通常是更小的类型更好，因为在数据中，类型也是有大小的，控制资源的浪费
  简单就好，通常会使用更少的cpu周期，比如时间的存储使用mysql自建类型，而使用字符串来存储会那 更好。
  尽量避免使用null，因为当表中查询值包含null时，会使其索引和计算等都比较复杂，加重cpu负担
  
  可以使用枚举来代替数据库当中的字符串，比如性别、状态等

2.合理使用范式和反范式

数据库三大范式不用多说了吧，三范式是为了减少我们的数据冗余，但在某些应用场景里面，你可能要应用到反范式，需要冗余一部分的数据，

查询数据最好不要join超过三张表，特别是大数量的话。这里也使用反范式和范式混合使用，这里要视实际应用场景变化

3.主键的选择

（二）有涉及到

4.字符集的选择

默认都是UTF8

5.索引存储的选择

默认都是innodb，是实际应用场景，考虑是否需要更换存储引擎

6.适当的冗余
7.适当拆分