数据库性能优化讲座 (2).ppt

关于数据库性能优化的讲座 研发部讲师介绍： 姓名：邵宗文 部门：研发中心 岗位：数据库平台主管 主要负责：公司数据库平台 2009年月6日 产品概要：给各个应用部门提供一个高可用的数据库平台服务。 产品目标：通过数据库平台，实现应用项目数据库的资源合理调配，让应用部门能够更加专注于产品代码开发，无需过多考虑后台数据库的部署和运维。 产品特色： 实现数据库的高可用，对有问题的数据库机器实现自动故障下线和自动修复上线。 针对数据库的各种状况的自动化监控，报警。 分布式多IDC的数据中心，既能提高南北用户访问体验，并能做到IDC级容灾和切换。 每天定时备份，保证了误操作之后几分钟之内相应数据恢复。 自动将相关慢日志sql发送给对应应用开发人员 依据各个应用项目的生命周期，进行机器资源的合理调配，给公司大大降低服务器成本。 数据库平台－－产品介绍 目前部署规模： 4个IDC数据中心（北京，天津，上海，广州），约50T的数据量，约有300个产品项目使用，重点产品包括财经，体育，发布，音乐，读书，UC,统一会员,空间app，朋友，圈子，汽车，科技，房产，博客广告分享平台等。 成本节省方面： 通过数据库平台，大大节约了公司的成本，解决了以前各个部门单独申请机器，导致项目出现冷热周期而出现机器低使用率问题。 重点产品优化案例： 在2007年财经特别火爆时候，数据库访问量急剧增大，同时实时性必须得兼顾情况下，后来财经自己把大部分数据库迁移到数据库平台之后，上述问题都被成功解决，并且多个财经产品如自选股，模拟炒股。 2008奥运会期间，数据库平台为体育部门成功解决了奥运期间数据量更新多，且实时性要求特别高的问题。 数据库平台－－成功案例 其他优化案例： 新浪北美，香港的数据库架构改造。 圈子数据库的重新设计和架构改造。 发布数据库的数据库架构改造。 UC数据库的迁移和架构重新改造 统一会员信息库的重新架构和改造 ? 目前数据库平台运维人员2人 数据库性能优化 数据库应用系统设计的性能考虑 数据库应用实现的性能优化 数据库参数的优化 缺省以MySQL 4.0/4.1/5.0，MyISAM表为主 何时需要优化 低层次 – 发现负载过高、性能下降时 一般 – 了解数据库处理机制，实现时优化索引 高层次 – 设计应用时，从表结构设计上保证 结构设计优化原则 1. 了解自己的应用 应用类型 读多写少（如体育项目），读写比例差不多（如邮件），和写多读少（如投票，统计） 预计数据量 半年？一年？后续扩展？? 决定单表还是多表，扩展的方法 预计访问量 多少读？多少写？峰值？? 几台服务器，主从方式 实时数据和非实时数据 哪些必须实时查询？哪些可以预先准备或近似？哪些用于统计汇总？ 时间的要求 实时性高的项目，如财经，体育，实时性低的项目如博客圈。 结构设计优化原则 2. 数据表尽量小 - 行数少，字段类型高效 - 为什么？ √IO高效 √全表遍历 √表级锁?提高并发度 √便于应用分布式结构 √可扩展性好 √alter table快 √损坏修复快 √ 备份和数据库重建时间短 - 手段： 分库、分表 使用最合适的类型长度，比如男女代码用tinyint就可以了，IP用varchar(15)就 一些如当天统计活跃用户的自己内部需要的数据可以用内存表。 应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 - 负面影响： 日志、统计等用途要慎选分表依据 分表原则的选择 按时间 按地区 按ID，手机号… 按hash值 要点：平均分担数据和负载 结构设计优化原则 3. 表数量的限制 -- 为什么？ - 受文件系统操作限制，文件数过大需要更多文件句柄，且大目录 操作造成复制、压缩、备份效率低。 - 打开表占用数据库资源（table_cache） -- 建议一个库不应超过300-400个表 -- 不当的设计： 长期运营的项目，每次活动一个（一组）表 -- 与“表尽量小”矛盾，一般来说表数量限制较严格 结构设计优化原则 4. 字段定义最好能适当 - 最费时的操作是行寻址，后续的整块读写延迟有限 - 分割字段可能意味着联合查询（join） 优点：数据逻辑清晰，冗余小，更新方便 缺点：临时表，优化复杂 - 可以接受适当的冗余和汇总数据 - 尽量