More Related Content
Similar to MySQL设计、优化、运维 (20)
More from Jinrong Ye (11)
MySQL设计、优化、运维
- 2. • 叶金荣，网络常用ID：yejr
• Oracle MySQL ACE
• 国内最早的MySQL推广者
• 2006年创办国内首个MySQL专业技术网站
http://imysql.com
• 资深MySQL专家，10余年MySQL经验，擅长
MySQL性能优化、架构设计、故障排查
- 4. 规范设计 – 原则
• 数据库就是数据库，不是计算器
• 读写分离，缓解在线库压力
• 合并写入、瞬间压力，分多次批量提交
• 本地写队列，防止意外崩溃丢失数据
• 垂直拆分，大数据字段独立拆分
• 水平拆分，冷热数据分离
• 数据压缩，在前端完成压缩
• 专用的统计库，分离线上应用
- 5. 规范设计 – 综合
• 最低授权：不开放非必要权限
• 资源预留：预留资源应付压力峰值
• 常见瓶颈：内存、IO(磁盘、网络)
• 分散压力：数据和日志区分存储
• 发挥优势：别让数据库做它不擅长的事
• 保持优雅：越小(少)越好
• 区分冷热：冷热数据区分开
• 保持一致：和生产环境一致
- 6. 规范设计 – 开发环境
• 开发环境和生产环境尽可能保持一致
• 启用log_queries_not_using_indexes
• 设置long_query_time为最小阀值
• 启用micro-time补丁
• 定期检查分析slow log
• 授权和生产环境一致
• 关闭Query Cache
• 设置较小InnoDB Buffer Pool
- 7. 规范设计 – 数据对象
• 默认使用InnoDB，尽量不用MyISAM
• 不对InnnoDB表进行在线实时统计
• InnoDB表显式指定自增INT型为主键
• 预先分库、分表或设定逻辑限制，减少在线单表
数据量
– 以用户ID=N为例，取N/100%100=30，取
N%100=20
– 则分配到DB30库下，分表TABLE20中
- 8. 规范设计 – 数据对象
• 表字段设计：简单至上
– INT/TIMESTAMP记录时间，而非DATETIME
– IPV4地址用INT，而不是CHAR(15)
– 性别即使有不男不女，也要用ENUM(1,2,3)，而不是
INT，甚至CHAR
– 杜绝TEXT、BLOG，确实需要则拆分
– 存储较长字符串内容时，提前进行(物理、逻辑)压缩、
序列化(JSON/BSON格式)
– 字段名显式而有意义，不用拼音，不用中文
- 9. 规范设计 – 数据对象
• 表字段设计：简单至上
– 相同用途的字段，在各个表里的定义属性完全一致
– 显式约束：NOT NULL
– 指定默认值：DEFAULT ‘’
– 选择合适的类型，不要用CHAR存储INT值
– 字段长度足够就行
- 10. 规范设计 – 数据对象
• 主键/唯一索性能引优于普通索引
• 复合索引比普通索引更合适
• 过度索引可能会带来灾难，够用就行
• 基数(cardinality)很小的列上不建索引
• 长字段使用部分索引，而非全部
• 冗余反向字段便于反向检索
• 采用第三方全文索引工具或者关键字(TAG)对
TEXT/BLOB/CHAR字段检索
• 常用检索、排序字段，需要创建索引
- 11. 规范设计 – SQL设计
• 简单SQL比复杂SQL高效
• 业务逻辑封装成存储过程
• 尽量不用子查询
• 减少使用复杂表连接
• 查询条件中不使用函数
• 用括号确定AND、OR优先级
• 查询条件加引号可能导致类型转换
• 不用FOR UPDATE和LOCK IN SHARE MODE，
防止锁扩大
- 13. 性能优化 – 综合
• 理解业务，切合业务特点的优化效果最好
• 业务规划，容量预估，建立基线模型
• 压测数据采集，预留峰值
• 尽一切努力减少IO(磁盘、网络)
• 转变随机IO为顺序IO
• 努力提高内存利用率
• 上线前做好评估审核
- 14. 性能优化 – 架构设计
• 保持优雅：越小越好，单库100G内
• 垂直拆分：按功能
• 水平拆分：按key哈希
• 单实例下数据表数量不高于1024
• 单表数据量尽量不高于1000万
• 主库写，从库只读、统计、汇总
• 前端做好一切cache
- 15. 性能优化 – 硬件
• NUMA架构，CPU直接和内存打交道
• CPU不再是瓶颈，MySQL多核支持不佳
• 设备越来越廉价，大内存解决很多问题
• SSD应用越来越广泛，未来是主力
• RAID卡可有效提升IOPS及数据安全
• RAID卡必须配备BBU，FORCE WB
• RIAD卡的条带设置有讲究
• FushionIO还是贵族
- 16. 性能优化 – 系统
• 升级到64位
• 内核
– IO调度：deadline，noop
– VM管理：vm.swappiness=0
• 文件系统：xfs、ext4
– 全B+树，高效
– 分配组，提高并发度
– 延迟分配，减少IO
– mount：nobarrier、data=ordered,writeback
• 加大请求队列：nr_requests
• 关闭NUMA
- 17. 性能优化 – MySQL
• 化繁为简
• 读写分离
• 加大内存分配
• 创建合适的索引
• 减少锁，提高并发
• 合并随机IO为顺序IO
• 柔风细雨优于狂风暴雨
• 多次批量提交优于频繁提交
• 使用XtraDB 或 MySQL 5.5+
- 18. 性能优化 – 调优工具
• systemtap
• sar
• gdb
• gcore
• oprofile
• pmp (Poor Man's Profiler)
• dstat
- 19. 性能优化 – 误区
• 分配内存越多越好，可能导致OS Swap
• session级内存分配过大，导致OOM
• 索引越多越好，可能导致更多IO
• Qcache设置过大，实际效果差
• 人云亦云，不自己动手实践
- 21. 运维管理 – 运维规范
• 硬件、系统、引擎、字符集选择
– 硬件
• 性能差不多，关键是可靠性
• 上线前烤机测试非常重要
• 监控预警可有效预防故障
• 避免使用外部阵列
• 最好是2U机型，并且配备RAID卡(with BBU)
– 系统
• 一般选择RHEL、CentOS
• 拒绝使用32位系统
• 不追新，稳定、高性能压倒一切
• 版本一致，批量部署，管理方便
- 22. 运维管理 – 运维规范
• 硬件、系统、引擎、字符集选择
– 引擎
• 默认使用InnoDB
• 可考虑MyISAM/InfiniDB/Infobright
• Blackhole可用于复制中继
– 字符集
• 默认使用latin1
• 减少使用utf8
• 避免CJK问题
• mysqldump字符集参数
• 连接串设置
- 23. 运维管理 – 运维管理
• 安装配置
– 所有磁盘组建大阵列，不降低IOPS
– 默认阵列级别为：raid 1+0
– 结合业务特征设置主机名，唯一命名
– 合理利用hosts/dns，可用于应用授权管理
– master和slave命名区分开
– /tmp使用/dev/shm & tmpfs
– swap至少是16G
– 部署基本工具包：sysstat、oprofile等
- 24. 运维管理 – 运维管理
• 监控预警
– 重点：先可用性而后才是性能
– 选择自己熟悉的：nagios、zabbix、cacti
– 作为补充，需要增加辅助监控
• 数据安全
– 关闭公网，只留私网
– 密码足够长度、复杂度
– 开启iptables策略
– 只开放必要的授权许可
– 使用普通账号管理mysqld(结合sudo)
– 集成定期安全检查到监控系统中
- 25. 运维管理 – 运维管理
• 备份恢复
– 利用slave执行备份
– 定期全备+及时增备
– 不定期随机做恢复测试
– 二进制内容备份使用 --hex-blob
– 备份方式：mysqldump VS XtraBackup
– 如何快速备份/恢复？(并发？快照？)
- 26. 运维管理 – 运维管理
• 高可用
– Keepalived + LVS
– Heartbeat + LVS
– Master + Slave
– 多Master共享存储
• 故障处理
– 复制报错：主键冲突
– 硬件、系统崩溃：数据页损坏
– 误操作：数据误删除
– 硬件故障：阵列卡(掉线、IO性能下降)、CPU、内存
- 27. 运维管理 – 工具集
• Percona、其他工具
– Xtrabackup
– ioprofile
– pt-online-schema-change
– pt-table-checksum
– pt-query-digest
– mysqldumpslow
– mysqlsla
- 28. 运维管理 – FAQ
• 数据库安装完后，无法启动
– 首先，看日志
– 一般因为权限不正确、未初始化、配置选项不正确
• 如何进行基准、压力测试
– 基准测试：tpcc、sysbench
– 压力测试：mysqlslap、前端加压
• 如何在线动态抓取SQL
– tcpdump -i eth0 -s 0 -l -w - dst port 3306|strings
• 如何执行在线热备
– mysqldump --single-transaction或Xtrabackup
