Skip to content

Latest commit

 

History

History
16 lines (14 loc) · 1.25 KB

advise.md

File metadata and controls

16 lines (14 loc) · 1.25 KB

MySQL使用约束及建议

关于性能的争论

最佳实践通常是为了获取最佳性能,但有可能一个支付环境,每秒只需要3000个事务就够了,更看重一致性。所以对于性能,关建是要明确一下定位,然后再跟据自已的情况来判到底使用那些招式组合。 读写分离: 对于非特殊要求的业务可以考虑部分SQL或是全量读SQL进行读写分离操作,从而增加DB的处理能力。 关于分库分表: 分库分表属于已经在DB的设计上无路可走,已经达到了前所未有的业务压力下才去走的一个技能。 通过常情况可以考虑优先进行硬件层面优化,SQL简化两个方向的工作,最后再来考虑分库分表,减少业务的复杂度。

建议

  1. 引擎可以选择: Innodb ,TokuDB
  2. 计算机在处理整数比较浮点数快N倍,慎用浮点数
  3. 尽量不要在DB里做运算,大的计算可以考虑中间件完成
  4. 尽量不使用MySQL UDF
  5. 简单的使用MySQL
  6. 目前不推荐在重要环境使用:外键, 分区表,存储过程等高级特性
  7. 数据库拆分中适合冗余
  8. 单库容量: SAS盘Raid 10 控制在500G左右, PCI-E卡,可以控制在卡的大小80%左右。 日志或是历史库除外