改变了对Mysql子查询的看法
这篇讲的是作者对MySQL查询优化的一次观念刷新。他过去从SQL Server转向MySQL时，发现官方文档更推荐JOIN，而子查询用`EXPLAIN`分析常表现不佳，于是形成了“MySQL子查询效率差”的刻板印象，在项目中一律改用JOIN写法。 然而一次线上故障改变了他的看法。网站因访问缓慢被排查，管理员发现涉及几张小表的查询平均耗时高达40秒。作者拿到慢查询日志，发现正是典型的JOIN写法，且`EXPLAIN`结果显示使用了临时表和文件排序。常规添加索引并未奏效，在尝试将JOIN改写为`IN`子查询后，执行计划瞬间变为使用索引，查询效率恢复正常。 作者随后对网站近10条类似语句进行了优化，网站整体速度得到显著提升。这个案例生动地说明了，数据库查询优化不应拘泥于固定的教条或过往的经验，必须针对具体的引擎版本、数据规模和执行计划进行实测与分析。MySQL的查询优化器在不同场景下对JOIN和子查询的选择可能存在差异，实践出真知。
mysql基本连接,mysqli,pdo,adodb,pearDB之间的区别，速度测试
这篇技术评测对比了PHP中五种主流的MySQL连接方式——原生mysql函数、mysqli扩展、PDO、ADODB以及PearDB——的性能差异。作者搭建了相同的测试环境，通过执行一系列标准数据库操作（如查询、插入）来记录各方案的响应时间，最终用直观的测试数据揭示了它们之间的速度阶梯。 从测试结果看，原生扩展（如mysqli和PDO）在执行效率上通常显著优于封装层较厚的数据库抽象库（如ADODB和PearDB）。这种差异源于它们与PHP引擎的耦合深度和额外的抽象开销。例如，mysqli提供了面向对象和过程化两种接口，并支持预处理语句，在安全与性能上较为平衡；PDO则以统一的接口支持多种数据库，在需要切换底层数据库时更具灵活性。 文章并未止步于速度排名，而是进一步探讨了不同场景下的选型逻辑：如果追求极致性能且项目仅针对MySQL，mysqli是可靠选择；若开发需要兼容多种数据库或重视代码的可移植性，PDO的抽象层价值就凸显出来。至于ADODB和PearDB，它们在快速原型开发或已有遗留项目中仍有用武之地。这篇实测为开发者在连接方案的选择上提供了具体的数据参考和实用思路。
MySQL 内部函数简介
这篇文章梳理了MySQL内置函数的核心分类与应用场景。作者从开发者日常高频操作切入，重点演示了算术运算子、字符串函数、日期处理函数等几类常用函数的用法差异。 例如，算术运算子不仅包含基础的加减乘除，还涉及取模、整除等容易忽略的细节；字符串函数则对比了`CONCAT`与`CONCAT_WS`在处理空值时的不同表现。文章通过具体SQL示例，展示了如何利用`IFNULL`简化空值判断，以及`DATE_FORMAT`在报表场景下的灵活应用。 掌握这些函数能直接提升查询效率，避免在业务逻辑中重复编写基础运算代码。文末汇总了函数使用中的常见陷阱，比如隐式类型转换导致的计算偏差，对实际开发有明确的避坑指导意义。
关于mysql proxy 0.7.0
这篇讲的是作者在升级到 MySQL Proxy 0.7.0 预发布版时，一并解决读写分离配置难题的实战经历。 作者从编译代码入手，重点分享了在实际环境中配置 MySQL 读写分离的过程。他坦言配置过程中遇到了不少“妖蛾子”，而且由于当时使用这个方案的人不多，相关资料匮乏，排错过程相当艰难。 不过最终，作者成功搭建并稳定运行了读写分离架构。文章没有停留在成功的结果上，而是详细记录了从遇到问题、摸索排查到最终解决的完整路径。这种来自一线、充满细节的分享，对于同样计划使用 MySQL Proxy 实现读写分离的开发者来说，具有很高的参考价值，能帮助他们少走弯路。
在centos 5.2下安装最新的mysql proxy
这篇文章聚焦于如何在较老的CentOS 5.2系统上部署最新的MySQL Proxy。作者从MySQL Proxy代码库已迁移至Launchpad并使用Bazaar进行版本管理这一背景出发，记录了一次在CentOS 5.2下编译安装的完整成功实践。 核心方案是基于源码的安装过程。作者详细分享了从获取代码、处理依赖到编译配置的关键步骤，并特别指出这些操作在CentOS 5.x系列上应该都是通用的。文章没有停留在理论，而是给出了实实在在的操作路径，为想在老版本系统上用上新工具的用户扫清了障碍。 对于需要在CentOS 5环境下使用MySQL Proxy进行数据库中间件开发或运维的人员来说，这篇记录为他们提供了一份扎实的、可复现的实操参考。
MySQL慢查询分析mysqldumpslow
这篇讲的是MySQL慢查询分析工具mysqldumpslow的实用指南。作者从日常积累的MySQL优化经验出发，系统地介绍了如何利用这个命令行工具快速从海量慢查询日志中提取关键信息。 文章聚焦于mysqldumpslow的核心功能，详细说明了如何通过不同参数（如-s、-t、-g）对查询按照执行次数、总耗时、平均锁时间等维度进行排序和筛选。例如，用“-s at”参数能立刻找出平均执行时间最长的查询，“-t 10”则可直接生成Top 10慢查询报告，这对于定位性能瓶颈非常直接有效。 相比通用的日志分析方案，mysqldumpslow胜在轻量、高效，且无需额外依赖，非常适合DBA和开发者在服务器上快速执行诊断。文中结合实际场景的参数组合示例，让工具的用法变得清晰易上手，为后续的SQL优化和索引调整提供了明确的数据切入点。
MyISAM和InnoDB的一些记录
这篇讲的是MySQL两种常见存储引擎MyISAM与InnoDB在配置思路上的关键差异，作者着重从参数调优的角度切入。文章的核心观点是，为MyISAM表优化性能时，key_buffer_size是最需要关注的参数之一——它直接决定了索引缓存能利用多少内存。如果主要使用MyISAM，建议将它设为可用内存的30%到40%，但这不是个固定值，最终得权衡索引大小、整体数据量以及实际负载。 与此同时，这也引出了与InnoDB的对比。InnoDB的性能调优重心则完全不同，其核心参数是buffer pool，用于缓存数据和索引。文章通过这个具体的配置建议，揭示了两种引擎底层设计哲学的不同：MyISAM重度依赖操作系统文件缓存来加速读取，而InnoDB则通过自带的缓冲池进行更主动、更精细的内存管理。理解这一点，就能明白为什么单纯增大MyISAM的key_buffer_size在混合负载下可能效果有限，而InnoDB的buffer pool调整通常能带来更直接的收益。对于正在纠结如何选择或配置存储引擎的开发者来说，这些从实践中总结出的记录提供了非常具体的参考。
Java数据类型和MySql数据类型对应表
开发者在Java应用中操作MySQL数据库时，经常遇到一个棘手的问题：Java和MySQL里的数据类型名称相似但不完全一致，如果不加注意，轻则查询结果类型转换报错，重则导致数据精度丢失或存储异常。这篇讲的就是这两种技术体系之间关键的数据类型对应关系。 文章直接提供了一份清晰完整的映射表，覆盖了开发中最常用的类型。比如Java的`int`对应MySQL的`INT`，`String`通常映射为`VARCHAR`或`TEXT`，`java.util.Date`则需要根据精度选择MySQL的`DATETIME`、`TIMESTAMP`或`DATE`。对于浮点数和大数值，作者特别指出了`float`/`double`与MySQL的`FLOAT`/`DOUBLE`可能存在的精度问题，推荐在涉及精确计算的金融场景中使用Java的`BigDecimal`对应MySQL的`DECIMAL`或`NUMERIC`。 除了基础对应，文章还深入分析了两者间的细微差异与适用场景。例如，MySQL的`TINYINT(1)`常被ORM框架自动映射为Java的`Boolean`类型，而`TIMESTAMP`和`DATETIME`在时区处理和范围上也存在区别。这些细节对于编写健壮的数据库访问代码至关重要。 总之，这篇文章就像一份随用随查的“翻译词典”，帮助开发者快速跨越Java与MySQL之间的类型鸿沟，避免常见的数据转换陷阱，是后端开发和数据库设计时的实用参考。
Mysql 4.1升级到5.0以后一个很郁闷的地方
这篇讲的是MySQL从4.1版本升级到5.0后出现的一个常见却令人困扰的问题。作者在一次数据库升级过程中发现，原本正常运行的系统在升级后突然出现大量数据乱码，尤其是在查询旧表时，字符显示异常。经过细致排查，根因在于MySQL 5.0默认字符集从latin1切换为utf8，而升级工具并未自动处理字符集转换，导致原有数据在新环境下无法正确解析。 作者详细描述了解决步骤：首先通过SHOW VARIABLES命令确认当前字符集设置，然后备份全库数据；接着修改my.cnf配置文件，临时将character-set-server设为latin1以保持兼容；之后使用ALTER TABLE命令逐表转换字符集，并优化了执行顺序以减少锁表时间。文章还强调了在生产环境中操作的风险，建议先在测试库验证脚本，并监控转换过程中的性能波动。最终，通过这一系列操作，数据库恢复正常，数据迁移顺利完成。 通过这个案例，读者能深刻理解版本升级中字符集兼容性的重要性，以及如何系统化地处理类似迁移任务，避免业务中断。
设置用于统计的冗余字段要谨慎
这篇讲的是作者在实际项目中为支持复杂统计功能，在数据表中添加冗余字段后所踩的“坑”。最初为了查询便利，直接在业务表里加了统计字段，但很快发现了一系列问题：数据同步困难导致统计结果与实时业务数据不一致，维护成本陡增，尤其在高并发写入时容易出现更新遗漏，反而让数据的可靠性打了折扣。 文章深入分析了这种“用存储换时间”思路的潜在风险。作者指出，冗余字段破坏了数据的单一事实来源，在业务逻辑复杂时，保证其与源字段的同步变得异常繁琐。他随后分享了更优的实践路径：将统计计算解耦，通过独立的统计服务或中间层来处理，避免污染核心业务模型。最终，系统不仅恢复了数据一致性，统计功能的扩展性也得到提升。 对于正在纠结是否通过加字段来优化查询的开发者，这篇提供了非常务实的技术决策参考。
Linux 64位, MySQL, Swap & Memory 优化
这篇讲的是如何在64位Linux环境下，针对MySQL的Swap和内存使用进行优化以提升性能。 文章从一个常见的性能瓶颈场景切入：当MySQL运行在64位Linux系统上时，系统默认的内存管理与交换空间（Swap）策略可能并不适合数据库这种内存密集型应用。作者指出，即便物理内存充足，系统也可能因不当的Swap配置导致性能下降。 核心方案聚焦在两个关键参数的调整上：`vm.swappiness` 和 `vm.overcommit_memory`。文章详细解释了这两个参数如何影响操作系统将MySQL的内存页面交换到磁盘的倾向，以及如何处理内存分配请求。通过具体的配置建议和调整逻辑，目标是让MySQL尽可能多地使用物理内存，减少昂贵的磁盘交换操作，从而降低延迟、提高查询吞吐量。 最后，文章通过对比优化前后的可能效果，说明这类系统层面的调优往往能带来立竿见影的性能改善，尤其是在内存压力较大的生产环境中。对于负责MySQL运维和性能优化的技术人员来说，这是一个值得审视和调整的基础配置方向。
MySQL介绍和性能优化 (PPT/PDF)
这篇讲的是MySQL数据库的基础认知与性能优化实践，以技术演示文稿的形式，系统梳理了从核心概念到调优技巧的关键知识。作者从“什么是MySQL”这一基本问题出发，快速搭建认知框架，随后深入到性能优化的核心战场。 文章的价值在于它不只罗列参数，而是将优化思路融入具体场景。比如，它清晰区分了索引优化、查询缓存调整和服务器配置升级等不同层级的手段，解释了每个措施解决的具体瓶颈——是减少了磁盘I/O，还是降低了CPU负载。通过对比优化前后的查询执行计划与响应时间，直观展示了不同策略的实际收益。 尤其值得一提的是，其中关于InnoDB存储引擎的内存与锁机制分析，揭示了许多性能问题的根源，比如为何看似简单的更新操作会变慢。这些内容让抽象的优化原则变得可操作。整个分享从原理到实例，为开发者提供了一份可以直接应用的MySQL性能诊断与调优指南。
Oracle10g 通过DBLink 连接MySQL5 数据库
这篇讲的是如何在Oracle10g数据库中，通过配置DBLink来建立与MySQL5数据库的跨平台连接。作者从企业实际开发中常遇到的异构数据库互操作需求出发，详细记录了这一配置过程。
核心方案聚焦于利用Oracle的透明网关或ODBC驱动作为桥梁。文章逐步拆解了关键步骤：从MySQL端准备驱动与用户授权，到Oracle端配置tnsnames.ora和init
Infobright的架构
这篇讲的是Infobright如何作为一款列式存储引擎，与MySQL无缝集成，以应对海量数据的分析型查询挑战。 文章首先指出了核心背景：传统行存数据库在面对复杂报表和聚合分析时，往往因I/O瓶颈而性能骤降。而Infobright的架构正是为解决这一问题而生。它本身不是一个独立的数据库，而是作为MySQL的一个存储引擎存在，这意味着用户可以在熟悉的MySQL生态中，享受到列存技术带来的分析加速。 其核心方案体现在几个关键架构设计上：数据按列组织和压缩，大幅减少了分析查询时需要读取的数据量；独特的“知识网格”技术用于元数据管理，能快速过滤无关数据块；并行处理能力则进一步提升了查询效率。这些设计共同使得它在处理大宽表和复杂查询时，性能可以比传统行存引擎高出数十倍甚至更多。 文章展示了其作为分析型引擎的定位和核心架构思想，但在具体的实现细节，例如知识网格的运作机制或压缩算法的取舍上，并未深入展开。这为读者勾勒出了一个清晰的技术蓝图，至于蓝图中的精密部件，则留待更感兴趣的读者去探索其源码或官方文档了。
高效的MySQL分页
这篇讲的是如何解决MySQL中分页查询的性能问题，特别是当数据量巨大时，传统的分页方式如何变得低效。文章的灵感源自雅虎工程师在2009年Percona性能大会上的一场经典报告，并在其基础上进行了深入拓展。 核心直指一个痛点：当你需要从百万、千万级数据中快速取出“第N页”记录时，简单的`LIMIT offset, count`语句可能导致数据库扫描大量不需要的行，造成严重性能拖累。作者从雅虎的实践出发，剖析了问题的根源，并引出了更高效的实现思路。 文章并没有停留在理论批判，而是进一步给出了可操作的优化方案和具体技巧，比如如何通过调整查询逻辑、利用索引来避免深分页带来的代价。这些结论在今天的大数据场景下依然有很强的参考价值，能直接帮助开发者写出响应更快的数据库代码。
根据status信息对MySQL服务器进行优化（二）
这篇续作深入MySQL性能优化的实战细节，核心工具是服务器自身输出的`SHOW STATUS`信息。作者没有泛泛而谈，而是将`STATUS`数据视作诊断现场的“仪表盘”，带领读者从数字中发现问题。 文章接着第一部分，聚焦于几个关键的状态计数器，例如分析`Created_tmp_disk_tables`与`Created_tmp_tables`的比值，来揭示临时表落盘导致的性能损耗；通过解读`Threads_running`等连接相关指标，判断是否存在高并发下的阻塞或线程调度瓶颈。它把抽象的性能问题，转化成了可以观察、可以计算的具体数字对比。 基于这些指标，作者给出了一系列可落地的调整建议，比如如何通过调整`tmp_table_size`和`max_heap_table_size`参数来减少磁盘临时表，以及怎样结合`Processlist`信息优化慢查询或连接池配置。整篇文章的逻辑是：从监控数据入手，定位到具体问题，再施以对应的参数或架构调整。 它将复杂的调优过程，拆解成了“看数据、找原因、调参数”这一步骤清晰的操作指南，对于需要从监控入手进行具体优化的DBA或开发人员，提供了直接可用的思路。
根据status信息对MySQL服务器进行优化（一）
这篇讲的是MySQL性能优化中容易被忽略的一条路径：不要只照搬通用的配置模板，而是学会“倾听”服务器自己的运行状态。作者从实际运维经验出发，指出了网上那些脱离具体硬件和应用场景的配置建议的局限性，核心思路是等待MySQL稳定运行一段时间后，去分析它的status信息——这相当于给数据库做了一次“全面体检”。 文章强调，这些状态数据里藏着真实的性能瓶颈线索。比如，通过关注诸如查询缓存（Query Cache）命中率、线程连接情况、表锁或行锁的等待时间等具体指标，我们能发现通用配置下未被暴露的问题：可能是某个高频查询未使用索引，也可能是内存分配不合理导致了频繁交换。作者传递的方法论是，优化应始于诊断，基于数据，而非盲目调整参数。 这种方法让优化工作更具针对性，能直接对准业务负载下的实际痛点，避免了“一刀切”可能引发的副作用。对于需要让MySQL发挥出更佳性能的运维人员和开发者来说，学习解读这些内部“语言”是迈向深度调优的关键一步。
MySQL全文检索中不进行全文索引默认过滤词表(ft_stopword_file =>ft_precompiled_stopwords)
这篇讲的是MySQL全文检索功能中一个容易被忽视但至关重要的细节：停止词表。 很多人在使用MySQL全文索引时，可能会发现某些常见的单词（如 “a”、 “the”）在搜索时不起作用，或者查询结果不符合预期。这往往是因为触发了MySQL内置的“停止词”过滤机制。 文章的核心就围绕这个默认行为展开。它解释了`ft_stopword_file`系统变量以及与之关联的`ft_precompiled_stopwords`表。简单来说，MySQL内置了一个包含大量无意义或高频词汇的列表，索引和查询时会自动跳过这些词。作者指出了这个默认配置在不同MySQL版本间可能存在的差异，以及它带来的实际影响——例如，在一个包含短小词汇的业务数据集中，默认过滤可能导致相关文章被意外排除。 理解这个机制是排查全文检索相关问题的关键一步。如果你的应用场景需要对这些“停止词”进行精确索引或查询，就必须通过修改配置来禁用或自定义该列表。文章点明了这个隐藏的“过滤器”，为解决全文检索中的相关性偏差提供了明确的调整方向。
Mysql查询优化器浅析（下）
这篇讲的是MySQL查询优化器中的存取类型，作者从“下篇”延续上文，聚焦于第七部分“存取类型”的深入解析。文章系统对比了ALL、index、range、ref、const等常见存取类型，详细阐述了它们各自的技术含义和性能差异。例如，ALL代表全表扫描，通常效率最低，适用于数据量极小的场景；而const则通过主键或唯一索引直接访问，效率最高，适合精确查询。作者通过实际案例和EXPLAIN输出示例，展示了如何识别查询的存取类型，并针对不同场景给出优化建议。比如，在范围查询中，range类型比index更
Mysql查询优化器浅析（上）
这篇文章聚焦于MySQL数据库性能的核心枢纽——查询优化器。作者没有从复杂的调优技巧入手，而是选择回溯本源，从“优化器是什么”这个定义开始，层层展开。 它详细拆解了优化器在SQL执行链路中扮演的角色：如何接收解析后的语句，如何基于成本模型评估不同的执行计划（比如全表扫描还是走索引），并最终选出它认为最优的一条路径。文章还点出了理解这一点对开发者的实际意义——当你发现查询慢时，问题可能不光在索引，更在于优化器为何做出了“错误”的选择。 作为系列开篇，这篇为后续深入探讨优化器算法（如CBO与RBO）打下了必要的基础，帮助读者建立起从SQL语句到实际执行动作之间的逻辑桥梁。