InnoDB内存优化

InnoDB用一块内存区域做I/O缓存池，该缓存池不仅用来缓存InnoDB的索引块，而且也用来缓存InnoDB的数据块。

1、innodb_log_buffer_size

决定了InnoDB重做日志缓存的大小，可以避免InnoDB在事务提交前就执行不必要的日志写入磁盘操作。

2、设置Innodb_buffer_pool_size

改变量决定了InnoDB存储引擎表数据和索引数据的最大缓存区大小。

MyISAM内存优化

MyISAM存储引擎使用key_buffer缓存索引模块，加速索引的读写速度。对于MyISAM表的数据块，mysql没有特别的缓存机制，完全依赖于操作系统的IO缓存。

1、read_rnd_buffer_size

对于需要做排序的MyISAM表查询，如带有order by子句的sql，适当增加read_rnd_buffer_size的值，可以改善此类的sql性能。但需要注意的是read_rnd_buffer_size独占的，如果默认设置值太大，就会造成内存浪费。

2、key_buffer_size设置

key_buffer_size决定MyISAM索引块缓存分区的大小。直接影响到MyISAM表的存取效率。对于一般MyISAM数据库，建议1/4可用内存分配给key_buffer_size:

key_buffer_size=2G

3、read_buffer_size

如果需要经常顺序扫描MyISAM表，可以通过增大read_buffer_size的值来改善性能。但需要注意的是read_buffer_size是每个seesion独占的，如果默认值设置太大，就会造成内存浪费。

调整MySQL参数并发相关的参数

1、调整max_connections

提高并发连接

2、调整thread_cache_size

加快连接数据库的速度，MySQL会缓存一定数量的客户服务线程以备重用，通过参数thread_cache_size可控制mysql缓存客户端线程的数量。

3、innodb_lock_wait_timeout

控制InnoDB事务等待行锁的时间，对于快速处理的SQL语句，可以将行锁等待超时时间调大，以避免发生大的回滚操作。

关于日志：

日志就跟人们写的日记一样，记录着过往的事情。但是人的日记是主观的（记自己想记的内容），而数据库的日志是客观的，根据记录内容分为以下好几种日志：


a、错误日志：记录启动、运行或停止mysqld时出现的问题。

b、通用日志：记录建立的客户端连接和执行的语句。

c、更新日志：记录更改数据的语句。该日志在MySQL 5.1中已不再使用。

d、二进制日志：记录所有更改数据的语句。还用于复制。

e、慢查询日志：记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。

f、Innodb日志：innodb redo log

缺省情况下，所有日志创建于mysqld数据目录中。

可以通过刷新日志，来强制mysqld来关闭和重新打开日志文件（或者在某些情况下切换到一个新的日志）。

当你执行一个FLUSH LOGS语句或执行mysqladmin flush-logs或mysqladmin refresh时，则日志被老化。

对于存在MySQL复制的情形下，从复制服务器将维护更多日志文件，被称为接替日志。

慢查询日志

MySQL会记录下查询超过指定时间的语句，我们将超过指定时间的SQL语句查询称为慢查询，都记在慢查询日志里，我们开启后可以查看究竟是哪些语句在慢查询。

开启慢查询日志

mysql>show variables like “%slow%”; 查看慢查询配置，没有则在my.cnf中添加，如下

推荐用分析日志工具 – mysqlsla

queries total: 总查询次数 unique:去重后的sql数量

sorted by : 输出报表的内容排序

最重大的慢sql统计信息, 包括 平均执行时间, 等待锁时间, 结果行的总数, 扫描的行总数.

Count, sql的执行次数及占总的slow log数量的百分比.

Time, 执行时间, 包括总时间, 平均时间, 最小, 最大时间, 时间占到总慢sql时间的百分比.

95% of Time, 去除最快和最慢的sql, 覆盖率占95%的sql的执行时间.

Lock Time, 等待锁的时间.

95% of Lock , 95%的慢sql等待锁时间.

Rows sent, 结果行统计数量, 包括平均, 最小, 最大数量.

Rows examined, 扫描的行数量.

Database, 属于哪个数据库

Users, 哪个用户,IP, 占到所有用户执行的sql百分比

Query abstract, 抽象后的sql语句

Query sample, sql语句

关于编码的大坑：

1.MySQL的“utf8mb4”是真正的“UTF-8”。

2.MySQL的“utf8”是一种“专属的编码”，它能够编码的Unicode字符并不多。

我要在这里澄清一下：所有在使用“utf8”的MySQL和MariaDB用户都应该改用“utf8mb4”，永远都不要再使用“utf8”。

那么什么是编码？什么是UTF-8？

我们都知道，计算机使用0和1来存储文本。比如字符“C”被存成“01000011”，那么计算机在显示这个字符时需要经过两个步骤：

1.计算机读取“01000011”，得到数字67，因为67被编码成“01000011”。

2.计算机在Unicode字符集中查找67，找到了“C”。

同样的：

1.我的电脑将“C”映射成Unicode字符集中的67。

2.我的电脑将67编码成“01000011”，并发送给Web服务器。

几乎所有的网络应用都使用了Unicode字符集，因为没有理由使用其他字符集。

Unicode字符集包含了上百万个字符。最简单的编码是UTF-32，每个字符使用32位。这样做最简单，因为一直以来，计算机将32位视为数字，而计算机最在行的就是处理数字。但问题是，这样太浪费空间了。

UTF-8可以节省空间，在UTF-8中，字符“C”只需要8位，一些不常用的字符，比如“”需要32位。其他的字符可能使用16位或24位。一篇类似本文这样的文章，如果使用UTF-8编码，占用的空间只有UTF-32的四分之一左右。

MySQL的“utf8”字符集与其他程序不兼容，它所谓的“”，可能真的是一大坑……

总结

如果你在使用MySQL或MariaDB，不要用“utf8”编码，改用“utf8mb4”。这里（ https://mathiasbynens.be/notes/mysql-utf8mb4#utf8-to-utf8mb4 ）提供了一个指南用于将现有数据库的字符编码从“utf8”转成“utf8mb4”。