Mysql配置优化，库表设计

Mysql 服务器参数类型：

基于参数的作用域：

　　全局参数：set global autocommit = ON/OFF;

　　会话参数(会话参数不单独设置则会采用全局参数)：set session autocommit = ON/OFF;

注意：全局参数的设定对于已经存在的会话无法生效，会话参数的设定随着会话的销毁而失效全局类的统一配置建议配置在默认配置文件中，否则重启服务会导致配置失效。

寻找配置文件不迷路：

mysql --help 寻找配置文件的位置和加载顺序

Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf

mysql --help | grep -A 1 'Default options are read from the following files in the given order'

全局配置文件配置：

　　最大连接数配置：max_connections，默认值151，可以再配置文件中修改该默认值。

　　当我们把这个连接数设置的尽量的大的时候，比如设置6000，会发现最后显示的结果只有4190，这是为什么呢？这是隐喻系统句柄数与mysql的句柄数的配置。

系统句柄数配置：可以在 /etc/security/limits.conf 文件中配置，通过 ulimit -a 命令可以查看 open files 的值。

mysql句柄数配置：可以通过文件 mysqld.service 设置参数 LimitNOFILE 的值来修改mysql的句柄数。

常见全局配置：

port = 3306
socket = /tmp/mysql.sock
basedir = /usr/local/mysql
datadir = /data/mysql
pid-file = /data/mysql/mysql.pid
user = mysql
bind-address = 0.0.0.0
max_connections=2000 #最大连接数
lower_case_table_names = 0 #表名区分大小写等于一不区分
server-id = 1 #服务编号
tmp_table_size=16M #在缓存存储引擎的时候的临时表的内存大小。
transaction_isolation = REPEATABLE-READ # 事务隔离级别
ready_only=1  # 对于数据表只有super用户的权限才能进行修改操作，从库的配置项

Mysql内存重要参数配置：

每一个connection内存参数配置：

sort_buffer_size connection排序缓冲区大小，建议256K(默认值)-> 2M之内，当查询语句中有需要文件排序功能时，马上为connection分配配置的内存大小

join_buffer_size connection关联查询缓冲区大小建议256K(默认值)-> 1M之内当查询语句中有关联查询时，马上分配配置大小的内存用这个关联查询，所以有可能在一个查询语句中会分配很多个关联查询缓冲区

上述配置4000连接占用内存：4000*(0.256M+0.256M) = 2G

Innodb_buffer_pool_size：innodb buffer/cache的大小（默认128M）这个参数是非常重要的，在 Innodb_buffer_pool(innoDB缓冲区)中包含了数据缓存，索引缓存，缓冲数据，内部结构等信息。

　　大的缓冲池可以减小多次磁盘I/O访问相同的表数据以提高性能。参考计算公式：Innodb_buffer_pool_size = （总物理内存 - 系统运行所用 - connection 所用）* 90%

Mysql 其他参数配置：

wait_timeout：服务器关闭非交互连接之前等待活动的秒数，默认值 8个小时。

innodb_open_files:限制Innodb能打开的表的个数

innodb_write_io_threads，innodb_read_io_threads：innodb使用后台线程处理innodb缓冲区数据页上的读写 I/O(输入输出)请求

innodb_lock_wait_timeout：InnoDB事务在被回滚之前可以等待一个锁定的超时秒数

常见配置的帖子：https://www.cnblogs.com/wyy123/p/6092976.html。

数据库设计：

第一范式（ 1NF）：

　　字段具有原子性,不可再分。 所有关系型数据库系统都满足第一范式）数据库表中的字段都是单一属性的， 不可再分；

第二范式（ 2NF）：

　　要求实体的属性完全依赖于主键。 所谓完全依赖是指不能存在仅依赖主键一部分的属性，如果存在， 那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体， 新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之， 第二范式就是属性完全依赖主键。

第三范式（ 3NF）：

　　满足第三范式（ 3NF） 必须先满足第二范式（ 2NF）。 简而言之， 第三范式（ 3NF）要求一个数据库表中不包含已在其它表中已包含的非主键信息。

简单一点：

1， 每一列只有一个单一的值，不可再拆分

2， 每一行都有主键能进行区分

3， 每一个表都不包含其他表已经包含的非主键信息。

潜藏的一些问题：

充分的满足第一范式设计将为表建立太量的列？

　　数据从磁盘到缓冲区，缓冲区脏页到磁盘进行持久的过程中，列的数量过多会导致性能下降。过多的列影响转换和持久的性能。

过分的满足第三范式化造成了太多的表关联？

　　表的关联操作将带来额外的内存和性能开销。

使用innodb引擎的外键关系进行数据的完整性保证？

　　外键表中数据的修改会导致Innodb引擎对外键约束进行检查，就带来了额外的开销。

常见的SQL军规：

　　军规适用场景：并发量大、数据量大的互联网业务

一、基础规范：

（1）必须使用InnoDB存储引擎

　　解读：支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高

（2）必须使用UTF8字符集 UTF-8MB4

　　解读：万国码，无需转码，无乱码风险，节省空间

（3）数据表、数据字段必须加入中文注释

　　解读：N年后谁tm知道这个r1,r2,r3字段是干嘛的

（4）禁止使用存储过程、视图、触发器、Event

　　解读：高并发大数据的互联网业务，架构设计思路是“解放数据库CPU，将计算转移到服务层”，并发量大的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实现“增机器就加性能”。数据库擅长存储与索引，CPU计算还是上移吧

（5）禁止存储大文件或者大照片

　　解读：为何要让数据库做它不擅长的事情？大文件和照片存储在文件系统，数据库里存URI多好

二、命名规范

（6）只允许使用内网域名，而不是ip连接数据库

（7）线上环境、开发环境、测试环境数据库内网域名遵循命名规范

（8）库名、表名、字段名：小写，下划线风格，不超过32个字符，必须见名知意，禁止拼音英文混用

（9）表名t_xxx，非唯一索引名idx_xxx，唯一索引名uniq_xxx

三、表设计规范

（10）单实例表数目必须小于500

（11）单表列数目必须小于30

（12）表必须有主键，例如自增主键

　　解读：a）主键递增，数据行写入可以提高插入性能，可以避免page分裂，减少表碎片提升空间和内存的使用

　　　　   b）主键要选择较短的数据类型， Innodb引擎普通索引都会保存主键的值，较短的数据类型可以有效的减少索引的磁盘空间，提高索引的缓存效率

　　　　   c） 无主键的表删除，在row模式的主从架构，会导致备库夯住

（13）禁止使用外键，如果有外键完整性约束，需要应用程序控制

　　解读：外键会导致表与表之间耦合，update与delete操作都会涉及相关联的表，十分影响sql 的性能，甚至会造成死锁。高并发情况下容易造成数据库性能，大数据高并发业务场景数据库使用以性能优先

四、字段设计规范

（14）必须把字段定义为NOT NULL并且提供默认值

　　解读：a）null的列使索引/索引统计/值比较都更加复杂，对MySQL来说更难优化

　　　　   b）null 这种类型MySQL内部需要进行特殊处理，增加数据库处理记录的复杂性；同等条件下，表中有较多空字段的时候，数据库的处理性能会降低很多

　　　　  c）null值需要更多的存储空，无论是表还是索引中每行中的null的列都需要额外的空间来标识

　　　　  d）对null 的处理时候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in这些操作符号。如：where name!=’shenjian’，如果存在name为null值的记录，查询结果就不会包含name为null值的记录

（15）禁止使用TEXT、BLOB类型

　　解读：会浪费更多的磁盘和内存空间，非必要的大量的大字段查询会淘汰掉热数据，导致内存命中率急剧降低，影响数据库性能

（16）禁止使用小数存储货币

　　解读：使用整数吧，小数容易导致钱对不上

（17）必须使用varchar(20)存储手机号

　　解读：a）涉及到区号或者国家代号，可能出现+-()

　　　　   b）手机号会去做数学运算么？

　　　　   c）varchar可以支持模糊查询，例如：like“138%”

（18）禁止使用ENUM，可使用TINYINT代替

　　解读：a）增加新的ENUM值要做DDL操作

　　　　  b）ENUM的内部实际存储就是整数，你以为自己定义的是字符串？

五、索引设计规范：

（19）单表索引建议控制在5个以内

（20）单索引字段数不允许超过5个

　　解读：字段超过5个时，实际已经起不到有效过滤数据的作用了

（21）禁止在更新十分频繁、区分度不高的属性上建立索引

　　解读：a）更新会变更B+树，更新频繁的字段建立索引会大大降低数据库性能

　　　　   b）“性别”这种区分度不大的属性，建立索引是没有什么意义的，不能有效过滤数据，性能与全表扫描类似

（22）建立组合索引，必须把区分度高的字段放在前面

　　解读：能够更加有效的过滤数据

六、SQL使用规范：

（23）禁止使用SELECT *，只获取必要的字段，需要显示说明列属性

　　解读：a）读取不需要的列会增加CPU、IO、NET消耗

　　　　   b）不能有效的利用覆盖索引

（24）禁止使用INSERT INTO t_xxx VALUES(xxx)，必须显示指定插入的列属性

　　解读：容易在增加或者删除字段后出现程序BUG

（25）禁止使用属性隐式转换

　　解读：SELECT uid FROM t_user WHERE phone=13812345678 会导致全表扫描，而不能命中phone索引

（26）禁止在WHERE条件的属性上使用函数或者表达式

　　解读：SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15' 会导致全表扫描，正确的写法是：SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-1500:00:00')

（27）禁止负向查询，以及%开头的模糊查询

　　解读：a）负向查询条件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，会导致全表扫描

　　　　   b）%开头的模糊查询，会导致全表扫描

（28）禁止大表使用JOIN查询，禁止大表使用子查询

　　解读：会产生临时表，消耗较多内存与CPU，极大影响数据库性能

（29）禁止使用OR条件，必须改为IN查询

　　解读：旧版本Mysql的OR查询是不能命中索引的，即使能命中索引，为何要让数据库耗费更多的CPU帮助实施查询优化呢？

（30）应用程序必须捕获SQL异常，并有相应处理

　　总结：大数据量高并发的互联网业务，极大影响数据库性能的都不让用，不让用哟。