Mysql相关知识点总结

字符集相关问题

1、如果出现数据库数据显示乱码请从三个方面解析
- 客户端字符集
- 服务端字符集
- 连接工具字符集

其中客户端字符集临时生效使用set name utf8，如果想要永久生效，请在my.cnf配置文件配置，并重启mysql

2、常用的集中字符集
- GBK：不是国际字符，对中文字符支持比较好，一个字符占两个字节
- utf-8：在中英文混合的情况下适合使用，每个中文字符都占三个字节
- latin1：mysql的默认字符集，每个字符占一个字节
- utf8mb4：UTF-8 unicode，每个字符占四个字节

3、如何选择mysql的字符集设置，这里分几种情况记录一下
- 如果处理各种各样的文字，发布到不同语言国家地区，应选择Unicode字符集，对mysql来说就是UTF-8，如果要使用英文，仅使用少量的UTF-8更好
- 如只需要支持中文，性能也要求比较高，可选GBK，如果需要大量运算，比较排序等，定长字符集，更快，性能更高。
- 处理移动互联网业务，可以需要使用utf8mb4字符集

4、如何修改已有的数据字符集
- 不能直接使用alter databases character set *，这个命令没有更新已有记录的字符集，而只是对新创建的表或者记录生效。
- 已有记录的字符调整，必须先将数据导出，经过修改字符集后重新导入后才可完成

5、修改字符集步骤
1）、建库及建表的语句导出，sed批量修改改为utf8
2）、导出所有mysql数据
3）、修改mysql服务端和客户端编码为utf8
4）、删除原有的库表及数据
5）、导入新的建库及建表的语句
6）、导入mysql的所有数据

6、备份语句

mysqldump -uroot -p --quick --no-create-info --extended-insert 、--default-character-set=latin dbname >alldata.sql

参数说明：
--quick：用于转储大的表，强制mysqldump从服务器一次一行的检索数据而不是检索所有行，并输出钱cache到内存中
--no-create-info：不创建create table语句
--extended-insert：使用包括几个VALUES列表的多行INSERT语法，这样文件更小，IO也小，导入数据时会非常快。
--default-character-set=latin1 #按照原有字符集导出数据，这样导出的文件中，所有中文都是可见的，不会保存成乱码。

mysql备份

1、备份的时候加入-B参数，增加创建数据库和连接数据库的命令,如

mysqldump -uroot -proot --default-character-set=latin1 -B test >/opt/mysql_test.sql

2、优化备份文件减少输出注释（测试调试用，生产不用）
利用mysqldump的–compact参数优化下备份
参数说明：
该选项使得输出内容更简洁，不包括默认选项中各种注释，有如下几个参数的功能
--skip-add-drop-table，--no-set-name，--skip-disable-keys，--skip-add-locks

3、指定压缩命令压缩备份的mysql数据

mysqldump -uroot -proot --default-character-set=latin1 -B test|gzip >/opt/mysql_test.sql.gz

压缩效果将近3倍

4、如何同时备份多个库

mysqldump -uroot -proot -B test test1|gzip >/opt/mysql_test.sql.gz

-B参数表示连接多个库，并且增加use db，create db的信息

5、做数据的分库分表备份

mysql -uroot -proot -e "show databases;"|grep -Evi "database|infor|perfor"|sed -r 's#^[a-z].*$#mysqldump -uroot -proot --events -B \1|gzip >/opt/bak/\1.sql.gz#g'|bash

6、做分表备份

mysqldump -uuser -ppassword 数据库名 表1 表2 表3 >/opt/test_table.sql

7、mysqldump的关键参数备份
1）、-B指定多个库，增加建库语句和use语句
2）、--compact去掉注释，适合调试输出，生产不用
3）、-A所有库
4）、-F刷新binlog日志
5）、-x，--lock-all-tables
6）、-l，--lock-tables 锁表只读
7）、-d只备份表结构
8）、-t只备份数据
9）、--single-transaction 适合innodb事务数据备份
InnoDB表再备份时，通常启用选项–single-transaction来保证备份的一致性，实际上它的工作原理是设定本次会话的隔离级别为：REPEATABLE READ,以确保本次会话（dump）时，不会看到其他会话已经提交了的数据

8、不同引擎备份方式不一样
myisam备份命令：

mysqldump -uroot -proot -A -B --master-data=2 -x|gzip >/opt/all.sql.gz
mysqldump -uroot -proot -F -A -B --lock-all-tables|gzip >all.sql

恢复命令：
gunzip < agent.gz | mysql -uroot -pxxxx  databases

Innodb备份命令：推荐使用

mysqldump -uroot -proot -A -B --master-data=2 --events --single-transaction|gzip >/opt/all.sql.gz
mysqldump -uroot -proot -F --single-transaction -A -B|gzip >all.sql

9、二进制恢复mysql的binlog日志
使用命令：mysqlbinlog日志

10、企业场景全量和增量的频率是怎么做的呢？
1）中小公司，全量一般是每天一次，业务流量低谷执行全备，备份时会锁表
2）单台数据库，如何增量，用rsync（配合定时任务频率大点，或者inotify，主从复制）把所有binlog备份到远程服务器
如：rsync -avz /data/3306/mysql-bin.000* [email protected]::backup --password-file=/etc/rsync.password
3）大公司周备，每周六00点一次全量，下周日-下周六00点前都是增量备份
优点：节省备份时间，减小备份压力，缺点：增量的binlog文件副本太多，还原会很麻烦
4）一主多从，会有一个从库做备份，延时同步

11、mysql的mysqldump备份什么时候派上用场
1）迁移或者升级数据库时
2）增加从库时候
3）因为硬件或特殊异常情况，主库或从库宕机，从库可以互相切换，无需备份
4）人为的DDL,DML语句，住从库没办法，所有库都会执行，此时需要备份

数据库恢复

1、指定开始位置和结束位置

mysqlbinlog mysqlbin.000021 --start-position=510 --stop-position=1312 -r pos.sql

输出 初始位置510,结束位置1312的所有binlog日志到pos.sql
注意：结尾的日致点比较特殊，不会被包含，即输出1312pos以前的binlog，位置点信息一般要实际存在，不能乱指定

2、指定开始位置到文件结束

mysqlbinlog mysqlbin.000021 --start-position=510 -r pos510-end.sql

输出开始位置510到文件结尾的所有binlog到pos510-end.sql

3、增量恢复的流程
1）停止一个从库，然后再主库刷新binlog，把mysql-bin.000014恢复成bin.sql（去掉drop语句）
2）把全备bak_2014-11-06.sql及10点前的增量bin.sql恢复到从库
3）切换到从库提供服务

主从复制

1、主从不一致，如何切换
1）、从主库拉取不一致的部分，导入（百度这样干的）
2）、双写
3）、通过应用程序写一个1分钟暂时日志
4）、把异步同步换成实时同步（谷歌开发出一个半同步插件，）
5）、drbd a,d,c三个等级

2、mysql主从同步配置步骤
1）、配置my.cnf文件，主库配置log-bin和server-id参数，从库配置server-id，不能和其他从库一样，一般不开启从库log-bin功能，注意：配置参数后要重启生效
2）、登陆主库增加用于从库连接主库同步的账户并授权replication slave同步的权限
3）、登陆主库，整库锁表flush table with read lock（窗口关闭后失效，超时参数到了也失效），然后show master status查看binlog的位置状态
4）、linux命令备份到处原有的数据库数据，并拷贝到从库所在的服务器目录，如果数据量大，并且允许停机，可以停机打包，而不用mysqldump
5）、解锁主库，unlock tables;
6）、show slave status\G，检查同步状态，并在主库进行更新测试
补充：
5.1：flush tables with read lock
5.5：flush table with read lock

双写如何解决自增不一致的问题
1、设置相同步长，设置不同id
如：
master1：
auto_increment_increment =2：自增ID的间隔，如1 3 5 间隔为2
auto_increment_offset = 1 ：ID的初始位置
master2：
auto_increment_increment = 2：自增的ID间隔，如2 4 6
auto_increment_offset = 2：ID的初始位置

3、快速主从配置
备份的时候指定参数–master-data=1，在maste.info即使不指定位置点和文件都没事，直接导入从库即可

数据库优化

1、配置优化
innodb_flush_log_at_trx_commit=0,每个事务提交的时候，每隔一秒写入log file，同时刷到磁盘
innodb_flush_log_at_trx_commit=1，每当提交事务，同时刷入log file和磁盘
innodb_flush_log_at_trx_commit=2，每当事务提交，马上写入log file，每隔1秒写入磁盘
当设置为0时性能最高但不安全，1最安全，但速度相对比较慢，当设置为2时，比1块，比0安全

1、硬件优化
cpu 64位CPU，一台机器8-16颗CPU，2-4颗
mem 96G-128G，32-64跑两个实例
disk 数量越多越好，性能：ssd>sas>sata，raid 4块盘：raid0>raid10>raid5>raid1
网卡，多块网卡bond，以及buffer,tcp优化

2、软件优化
操作系统：x86_64位
软件：mysql编译优化

3、my.cnf参数优化，大部分架构以及SQL语句优化

4、SQL语句的优化
a.索引优化
慢查询日志分析工具：mysqldumpslow，myprofi，mysql-explain-slow-log，mysqllogfilter
b、大的sql语句拆分成多个小的SQL语句
c、数据库是存储数据的地方，但是不是计算数据的地方
d、搜索功能，like ‘%老男孩%’，一般不要用mysql数据库
e、每天晚上0点分析慢查询，发到核心开发，DBA分析，及高级运维，CTO邮箱里面
DBA分析给出优化建议–核心开发确认更改–DBA线上操作处理

5、架构上的优化
1、业务拆分：like’%test%‘，一般不用mysql数据库
2、业务拆分，某些业务使用nosql持久化存储
3、数据库前端必须要加cache
4、动态的数据静态化，整个文件静态化，页面片段静态化
5、数据库集群与读写分离，一主多从，通过程序或者dbproxy进行集群读写分离
6、单表超过2000万，拆库拆表，人工拆表拆库

6、流程，制度，安全优化
任何一次人为数据库记录的更新，都要走一个流程
a、人的流程：开发–核心开发–运维DBA
b、测试流程：内网测试–idc测试–线上执行
c、客户端管理，phpmyadmin

读写分离

通过程序
生产基本不用代理软件：mysql-proxy,amoeba
生产：分布式dbproxy，读写分离，hash负载均衡，健康检查