mysql索引的一个技巧
这篇讲的是MySQL索引设计中一个关于范围查询与排序结合的经典技巧。 作者从一条常见的查询入手：`SELECT * FROM table WHERE col1 > number ORDER BY col2 DESC`。许多人会习惯性地建立组合索引 `KEY(col1, col2)`，但这在MySQL中并非最优解。关键原因在于，当`WHERE`条件对索引前导列使用范围查询时，后续的`ORDER BY`部分很可能无法继续利用索引来避免排序，导致性能不佳的filesort操作。 文章指出了优化的核心：调整索引列的顺序。通过构建索引 `KEY(col2, col1)`，并在查询中为`col2`增加一个逻辑上等价于无约束的范围条件（如 `col2 > min_value`），就能让`ORDER BY col2 DESC`直接利用索引的有序性，从而同时满足查询和排序，消除了filesort。这种设计的巧妙之处在于，它利用了“当范围查询是等值查询的退化形式”时的索引优化原理。 这个技巧揭示了在组合索引中，索引列的顺序需要精确匹配查询模式（等值在前，范围在后）。它在实际优化中非常实用，尤其当查询同时涉及范围过滤和排序时，能带来显著的性能提升。
varchar(10) 和varchar(100)的区别？
这篇文章直接切入一个看似简单但常被忽略的数据库细节问题：`varchar(10)` 和 `varchar(100)` 到底有什么区别？ 作者用一个非常直观的例子点明了核心：如果只存储“hello”这样的短字符串，两者在底层占用的存储空间都是相同的（例如MySQL中为6字节）。这打破了许多人“长度定义越大越浪费空间”的直觉误解。 然而，真正的差异并不体现在静态存储上，而在于这个长度定义所代表的“承诺”与边界。字段定义的长度限制了它能存入的最大字符数，这直接影响到数据校验和应用层逻辑。更重要的是，在某些数据库实现中，这个预定义的长度会影响查询优化器对索引使用和内存分配的决策，从而间接关系到查询性能。文章澄清了选择依据：应该基于业务中该字段未来可能存储的最大内容长度来合理设定，而非随意设置一个“足够大”的值，从而在存储清晰度与潜在性能之间做出平衡。 通过这个对比，文章澄清了开发者心中长久的一个疑虑，将关注点从单纯的存储空间引向了更根本的字段设计原则。
MySQL在切换binlog时会阻塞更新
这篇讲的是一个实际运维中遇到的MySQL性能陷阱。作者发现，在使用MySQL 5.0.51版本时，当binlog文件因达到`max-binlog-size`设定的上限（如700MB或更高）而进行切换时，会导致数据库的所有更新操作出现短暂的完全阻塞。 问题的根因最终指向了binlog的切换机制本身，但具体触发条件与文件大小阈值密切相关。作者通过对比慢查询日志的时间点与新建binlog的时间，成功复现了这一现象，从而定位了问题源头。 目前该问题的直接原因尚不明确，但有一个简单有效的规避方案：将`max_binlog_size`参数调小，例如设置为600MB。如果业务对极端情况下的插入延迟或超时不敏感，也可以选择暂不处理。这篇文章的价值在于揭示了一个容易被忽视的配置细节，并提供了经过验证的临时解决方法，对数据库管理员和开发者有直接的参考意义。
改变了对Mysql子查询的看法
这篇讲的是作者对MySQL查询优化的一次观念刷新。他过去从SQL Server转向MySQL时，发现官方文档更推荐JOIN，而子查询用`EXPLAIN`分析常表现不佳，于是形成了“MySQL子查询效率差”的刻板印象，在项目中一律改用JOIN写法。 然而一次线上故障改变了他的看法。网站因访问缓慢被排查，管理员发现涉及几张小表的查询平均耗时高达40秒。作者拿到慢查询日志，发现正是典型的JOIN写法，且`EXPLAIN`结果显示使用了临时表和文件排序。常规添加索引并未奏效，在尝试将JOIN改写为`IN`子查询后，执行计划瞬间变为使用索引，查询效率恢复正常。 作者随后对网站近10条类似语句进行了优化，网站整体速度得到显著提升。这个案例生动地说明了，数据库查询优化不应拘泥于固定的教条或过往的经验，必须针对具体的引擎版本、数据规模和执行计划进行实测与分析。MySQL的查询优化器在不同场景下对JOIN和子查询的选择可能存在差异，实践出真知。
linux上ext2文件系统中，用debugfs来恢复被删除的文件
这篇讲的是在ext2文件系统上，如何利用debugfs工具将误删的文件找回来。作者从ext2的一个关键特性出发：执行rm命令时，其实只是删除了文件的索引，数据本身还保留在磁盘上，这为恢复提供了可能。 对于单个文件，操作很直接。打开debugfs连接设备，用`lsdel`找到被删文件的inode，再用`dump`命令就能将其导出。文章重点在于，当需要恢复成千上万个文件时，如何高效操作。作者演示了通过一条组合管道命令，先利用`lsdel`批量列出删除文件信息，再用grep和awk进行筛选（比如按用户、时间、文件大小），自动生成一个包含大量dump命令的脚本文件`cmd`。最后，一条`debugfs -f cmd`指令就能批量完成恢复，这省去了交互模式下手动生成命令的繁琐。 文章末尾还给出了一个至关重要的安全提示：如果系统有多块磁盘，恢复文件时务必指定保存到另一块磁盘。否则，dump过程写入的数据可能会覆盖掉其他尚未恢复文件的磁盘区域，导致数据永久丢失。
CakePHP View Cache的一个问题
这篇讲的是CakePHP中一个容易被忽视的缓存陷阱。作者在使用View Cache（视图缓存）时发现，一旦URL带有查询参数（比如 `?id=123`），缓存就始终无法命中，导致性能优化失效。 深入排查后，问题出在 `CacheHelper` 的缓存路径生成机制上。原来，它默认是将完整的请求URL作为缓存文件的存储路径。当URL包含可变的查询参数时，每个不同的参数组合都会生成一个独立的缓存文件，这实际上破坏了预期的缓存效果，让缓存形同虚设。 作者通过分析源码定位了根因。解决方案在于自定义缓存键的生成逻辑，在保存缓存时，需要剔除那些不影响页面内容的查询参数，确保相同内容的页面能复用同一份缓存文件。这个案例提醒我们，在使用框架缓存功能时，不能想当然，需要理解其底层实现，特别是当URL参数可能发生变化时，显式控制缓存键才能让缓存真正生效。