利用MySQL触发器高性能造数据
这篇讲的是一个关于MySQL触发器的有趣发现：它通常只用来做简单的表间更新，但有人用它在批量生成测试数据方面取得了意想不到的高性能效果。 文章作者首先用存储过程作为基准方案，在单线程下为一张包含1000万行记录的表造数据，耗时8分20秒，相当于每秒插入约2万条记录。这个速度本身已经不错。 但作者想测试触发器是否能做得更好。这里有个小限制：MySQL触发器不支持对同一张表进行自我插入，所以他额外创建了一张中转表tb3。核心方案是，为tb3创建一个`AFTER INSERT`触发器，当向tb3插入一条记录时，触发器会立即在目标表tb2中循环插入1000万条随机数据。 最终结果很亮眼：整个过程耗时5分14秒，相当于每秒插入超过3万条记录，比纯存储过程方案的速度提升了约60%。作者用“很HAPPY”来形容这个结果，因为通过一个简单的触发器设计，就显著优化了数据生成的吞吐量，为需要快速填充测试环境的场景提供了一个高效思路。
ORACLE的几个函数在MYSQL里面的简单实现
这篇讲的是数据库迁移中一个非常具体但又普遍的痛点：如何在目标数据库MySQL中，复现源数据库Oracle里的那些特有函数。作者正在执行一个Oracle到MySQL的迁移项目，他针对MySQL原生缺失的三个Oracle函数，提供了自己的MySQL实现方案。 文章没有泛泛而谈迁移策略，而是直接切入最实际的代码层面。作者分享了这三个函数在MySQL下的自定义实现逻辑，这对于正在面临同样迁移挑战的开发者来说，是即拿即用的宝贵参考。它解决的正是迁移过程中“最后一公里”的兼容性问题，能够帮助团队更平滑地完成数据与逻辑的过渡，避免因函数缺失而导致的业务逻辑重写。对于需要进行此类数据库切换的工程师而言，这篇内容提供了一种务实的问题解决思路。
关于Infobright 的几种数据格式
这篇讲的是Infobright数据库中几种关键数据存储格式的对比与选择。作者从实际应用场景出发，重点剖析了行式存储（如MyISAM）与列式存储（Infobright自有格式）在数据压缩、查询性能上的本质差异。文章用具体数据说明了列式存储在海量数据聚合查询中的速度优势，尤其是其独特的低层数据包与高精度元数据如何实现高压缩比和快速解压。同时也指出了行式存储在点查询和更新操作上的适用性。最后，作者结合不同业务负载特点，给出了格式选型的具体建议：分析型、读密集型场景优先考虑列式格式，而事务型或频繁更新的场景则需谨慎评估。
Infobright 数据仓库心得总结
这篇讲的是作者在实际项目中使用 Infobright 数据仓库的经验总结。Infobright 是一个基于 MySQL 的列式存储引擎，作者从自己的使用场景出发，梳理了它与传统行式数据库的关键差异。核心在于，Infobright 采用“粗粒度索引”和高性能数据压缩技术，这使得它在海量数据的分析查询场景下，尤其是数据仓库和报表类应用中，查询速度和数据压缩率远超常规的 MyISAM 或 InnoDB 引擎。 文章指出，这种架构的优势在面对只读或极少更新的大型数据集时尤为明显，但同时它的写入和更新性能相对较弱，因此更适合用于ETL处理后的结果存储与查询。作者通过具体的应用体会，点明了 Infobright “以空间换时间”、专注于加速分析型查询的设计哲学。 对于正在评估开源数据仓库方案，或者需要优化现有数据分析平台性能的技术团队来说，这篇基于实战的总结，清晰地划定了 Infobright 的能力边界与最佳适用场景。