高可用数据库平台架构及日常管理经验介绍.辫辫迟
- 5. 目前新浪数据库平台现状 多个 IDC 数据中心 Mysql5.0 数据库服务几百台 . ( 不断增长中 ) 约有几百 T 的数据量 . （线上 + 备份存档） 约有几百个项目产物使用。 平台重点产物有：财经，体育，统一通行证，无线 wap ，读书，音乐，空间 , 通用投票，博客圈，博客杂志，汽车，科技，发布系统等。
- 12. 数据库应用项目规划和优化原则 1. 了解自己的应用 应用类型 读多写少（如体育，读书），读写比例差不多（如音乐），和写多读少（如投票，统计） 预计数据量 半年？一年？后续扩展？ ? 决定单表还是多表，扩展的方法 (hash 分表 ) 预计访问量 多少读？多少写？峰值？ ? Com_select,Com_update(insert,delete) 实时数据和非实时数据 哪些必须实时查询？哪些可以预先准备或可以 cache ？哪些用于统计汇总？ 时间的要求 实时性高的项目，如财经，体育，实时性低的项目如博客圈等。
- 14. 2. 如何对大应用项目切分 保证数据库单个实例尽量不要超过 150G 。 切分尽量多的小实例，一个机器跑 7-8 个实例， 平常 load avg 不超过 1-2 ，峰值不超过 6-7 为合理。 分表原则的选择 按时间 ( 财经 ) 按 ID 号 hash 分 ( 统一通行证 ) 按业务项目 ( 通用投票 )
- 15. 3. 单库表数量的限制 -- 为什么？ - 受文件系统操作限制，文件数过大需要更多文件句柄，且大目录 操作造成复制、压缩、备份效率低。 - 打开表占用数据库资源（ table_cache ） √ 建议一个库不应超过 300-400 个表 √ 建议一般带 char 字段的表不应超过 500 万 rows. 基于数字的字段为主的表不要超过 1000 万 rows.
- 16. 4. 表的优化 正确使用索引，避免全表搜索 使用定长表 , 且定期做 OPTIMIZE TABLE 命令（注意这个命令会锁表，请在数据库访问小的时候做） 在对大表进行添加索引，一定要选择访问小的时间段做，否则会导致严重问题。 注 : 一般临晨 2-3 点时候是大部分项目访问的低谷。
- 17. 5. 索引优化、选择和试验 稳妥地改进 将需要优化的相关表复制到测试环境 在测试环境启动一个测试 daemon ，关闭 query cache 或是使用 select SQL_NO_CACHE 方式。 未优化时测试若干次查询时间，以及 explain 检查扫描集。 选择合适的索引试验建立。可以通过 use index(xx) 来强制使用。检查是否有效。 测试查询时间变化，反复试验得到最优结果 保持关注，根据情况随时改变索引设置
- 18. 6. 对于排序的问题 尽量使用带主键的字段做 order by 的排序 尽量不要多提供页面的查找（最好只提供 100 页内），避免机器爬虫抓取数据，导致数据库压力负载过高。因为做 order by field1 limit xxxxxx,20 是非常消耗数据库资源 。
![高可用数据库平台架构 及日常管理经验介绍 研发中心 邵宗文 [email_address]](https://image.slidesharecdn.com/random-090415055816-phpapp01/85/ppt-1-320.jpg)
