mysql优化 个人笔记 - 非礼勿扰 -m17

上一篇讲到了 datadir、socket、pid_file、port、default_storage_engine、skip-grant-tables、character_set_client、character_set_connection、character_set_results、character_set_database、character_set_server、max_connections、max_user_connections、back_log、wait_timeout、interactive_timeout

3. 日志

1. log_error
   指定错误日志文件名，用于记录当前mysql 启动和停止时，以及服务器在运行中发生的错误等相关信息
2. log_bin
   指定二进制文件名称，用于记录对数据库造成更改的所有执行语句

redo 归属于Innodb 就算数据没有及时写入磁盘 那这个redolog里还有操作记录 可以恢复
redolog 是固定大小 循环写的过程

undo 归属于Innodb 实现事物原子性 undolog记录的是操作相反的操作
比如我新增一条记录 那么undolog就记录一次删除

binlog 归属于MysqlServer 层面
binlog三种存储方式 ROW STATEMENT MIXED
binlog是顺序读写的

ACID 原子性 一致性 隔离性 持久性
A undolog实现
C AIC合起来实现
I 通过锁实现
D redolog 实现

日志三种方式 建议使用下图最后一种 直接写入os buffer 每秒从os buffer刷新到磁盘

Mysql数据更新流程

1. 执行器先从引擎中找到数据，如果在内存就直接返回，如果不在内存就从磁盘加载到内存再返回
2. 执行器拿到数据之后会先修改数据，然后调用引擎接口写入数据
3. 引擎将数据更新到内存，同时写入数据到redo中 此时处于prepare阶段 并通过执行器完成，随时可以操作
4. 执行器生成这个操作的binlog
5. 执行器调用引擎的事务提交接口，引擎把刚刚写完的redo改成commit状态 更新完成

RedoLog 两阶段提交
如果先redolog 在 binlog 那么如果redolog的时候服务器坏掉了 那么binlog的信息与redolg就不一致了
相反先记录binlog也是一样
所以搞了个两阶段提交 显示redolog的prepare阶段 再是binlog 最后再是redolog的commit阶段 这样保证了数据日志在逻辑上的一致性

如果出现问题时恢复流程：
1. 如果redolog 日志是完整的 prepare+commit 那么就直接提交事务
2. 如果redolog日志不完整，获取redolog的 prepare事务列表+binlog的最后一个Xid
    2.1 如果binlog事务完整 就提交
    2.2 如果binlog事务不完整 就回滚
3. binlog 与redolog通过checksum与xid进行完整性判断 通过Xid做事务关联
4. 这里我也是一头雾水 不是很明白 先记住两阶段提交 防止了数据不一致问题

7. binlog_do_db
   指定记录log_bin的数据库 没有指定的将不会被记录 如果不指定会全部记录了
   逗号隔开多个数据库
8. binlog_ignore_db
   指定不记录log_bin的数据库
   逗号隔开多个数据库
9. sync_binlog
   指定多少次写日志后 刷新到磁盘 （刚开始是存在内存的 为了提高性能）
10. general_log
    是否开启查询日志
11. general_log_file
    查询日志的文件名
12. slow_query_log
    是否开启慢查询日志
13. slow_query_log_file
    慢查询日志的文件名
14. long_query_time
    慢查询临界值， 超过long_query_time时间的查询 就是慢查询
15. log_slow_admin_statements
    是否将管理语句写入

缓存

1. key_buffer_size
   索引缓存区的大小，（只对myisam有效）

2. query_cache
   2.1 query_cache_size
   

   # 缓存中相邻内存的个数 如果值比较大 那么查询缓存中碎片比较多
   Qcache_free_blocks  
   # 查询缓存中 剩余内存的大小  
   Qcache_free_memory
   #  表示有多少次命中缓存
   Qcache_hits
   #  表示多少次未命中 而插入
   Qcache_inserts
   # 多少条query 因为内存不足而被移除cache
   Qcache_lowmem_prunes
   # 不能被cache 的Query 的数量
   Qcache_not_cached
   #  当前cache缓存的query数量
   Qcache_queries_in_cache
   # 当前cache的block的数量 
   Qcache_total_blocks
   

   2.2 query_cache_limit
   超出此大小的查询将不被缓存
   2.3 query_cache_min_res_unit
   缓存块最小的大小
   2.4 have_query_cache
   表示这个mysql版本是否支持查询缓存 8之后好像不支持了
   2.5 query_cache_type
   0时表示关闭，
   1时表示打开，
   2表示只要select 中明确指定SQL_CACHE才缓存
   2.6 query_cache_wlock_invalidate
   默认OFF |若表被写锁锁定，但查询命中缓存，仍返回结果；性能好，并发能力好
   ON更安全，保持数据一致性

3. sort_buffer_size
   需要排序的线程 分配该大小的缓冲区

4. max_allowed_packet=32M
   限制server接收的数据包大小

5. join_buffer_size=2M
   表示关联缓存的大小 如果第一个表中数据大于2M 就不会使用缓存了 可以调大一点
   不宜过高

6. thread_cache_size
   线程缓存大小 跟连接池一样了 连接会缓存起来 放到内存空间
   6.1 threads_cached 表示当前线程缓存中 有多少个空闲线程
   6.2 threads_connected 代表当前已经建立连接的数量
   6.3 threads_created 表示最近一次服务启动，已经创建线程的数量，如果值比较大，那么服务器会一直创建线程
   6.4 threads_running 代表当前激活的线程数

7. INNODB
   7.1 innodb_buffer_pool_size
   该参数指定大小的内存来缓冲数据和索引，最大可以设置为物理内存的80%
   7.2 innodb_flush_log_at_trx_commit
   主要控制innodb将log buffer中的数据写入日志文件并flush磁盘的时间点
   值分别是 0 1 2
   7.3 innodb_thread_concurrency
   设置innodb线程的并发数 默认为0表示不受限制，如果要设置建议和cpu核心数一样，或者是cpu核心数的2倍
   7.4 innodb_log_file_size
   日志文件的大小 M为单位
   7.5 innodb_log_buffer_size
   日志文件所用内存大小 M为单位
   7.6 innodb_log_files_in_group
   以循环方式将日志写入多个文件中 几个文件循环写
   7.7 innodb_read_buffer_size
   读入缓冲区的大小 对表进行扫描的请求将分配到一个读入缓冲区
   7.8 innodb_rnd_buffer_size
   mysql随机读取的缓冲区大小
   7.9 innodb_file_per_table
   此属性 确定为每一张表分配一个新的文件
   设置为on 每一张表都有一个独立文件
   如果为off 只有一个.frm 没有数据文件。。。
   数据都扔到 ibdata1 ，默认都是放表空间了 。。