浅谈性能优化

性能优化（Performance Turning）老生常谈的问题。确实也在几次面试中被问到过相关的问题。当时也就自己做过的几个小型优化说了下感受。

今天，部门组织了一场对公司业务系统的性能优化讨论。突然想到，这就是一个不错的应对当时面试的回答。今天在场的几位大牛加起来应该有100年开发功力了，还是挺值得把思路记录一下的。

现状与目标分析

现状分析：目前的性能是怎样的级别？用数字说话，例如处理多少条数据或请求，用时多少。瓶颈在何处？用压测分析不同系统、模块、步骤、甚至函数的消耗时间。找到瓶颈，针对耗时高的位置进行提升。
目标分析：性能要提高到怎样的程度？数量和时间。数量是百万级，千万级，亿级？是什么时候的目标？请业务拿出准确的数据和趋势分析。拍脑袋也请给个依据。在现在为3、5、7年后的业务目标做性能优化，那绝对是一个浪费。最后，要在多长的时间完成。

策略与选项

分析清楚以上两点后，接下来就是实实在在的招式了。数量凑不齐降龙十八掌，凑个独孤九剑还是可以。

1. 一了百了，低风险大招。请帮应用服务器和DB加硬件资源。CPU，Memory。效果必定有，但不明显就要深查代码和架构了。
2. 表分区和分表。关系型数据库，单表去到1千万数据就应该考虑做表分区了。如果接近2千万，应该考虑分表。使用日表，月表分别存储。还可以按业务类型分表。
3. 批量处理。尽量在内存里处理，程序批量处理后再批量写数据库。减少数据库连接使用。
4. 缓存，尽量把静态的，不常变的数据进行缓存。这里主要要小心缓存刷新。
5. 多线程。引入多线程提高并发处理。
6. 如果只是单纯的数据库操作，数据合并，使用存储过程。前提是不要包含复杂的业务逻辑。在数据处理时可以先在临时表中清洗处理，然后再写入业务表。
7. 考虑使用MQ代替文件传输。
8. 注意数据的归档和清理，保持业务主表轻量。
9. 各种SQL优化。针对分析中的瓶颈做程序的代码优化。

招式还有很多很多，思路就是拿着压测一步步向目标靠。代码、架构、SQL、数据库、硬件，拿着分析数据逐个击破。