MariaDB常见问题FAQ
这篇FAQ整理了MariaDB（也适用于MySQL）用户在实际使用中可能遇到的若干典型问题与解答。文章涵盖了从语法兼容性到性能排查的多个实战场景。 例如，在早期MySQL 5.1中，`via`并非保留字，但在MariaDB中使用则会导致1064错误，这是一个已修复的特定版本兼容性问题。另一篇关于“索引下推”的案例则展示了升级到MariaDB 5.5.23后，某个查询因优化器行为变化，执行时间从毫秒级暴跌至十几秒，通过设置`optimizer_switch`关闭该特性后恢复正常，该问题已被记录为Bug。 此外，文章还澄清了客户端在连接建立前就会提示输入密码的技术细节，并讨论了Amazon RDS的迁移方法。对于社区关心的`CHECK`约束支持，文中也给出了明确答复：当时尚无实现计划。 这些问答直接源于社区真实案例，具体且实用，能帮助开发者快速定位并解决类似环境中的常见困惑。
如何验证SQL PROFILE的性能？
这篇讲的是在Oracle数据库生产环境中，如何安全且有效地验证SQL PROFILE的实际性能收益。 文章开篇点明了背景：10g以后的SQL Tuning Advisor会给出多种调优建议，其中启用SQL PROFILE是常见选项。但在生产环境直接应用存在风险，因为优化建议未必适合真实负载，一旦出错可能加剧性能问题。尤其当缺乏测试环境，而SQL PROFILE又可能是“救命稻草”时，就需要一种可靠的局部测试方法。 作者随即演示了具体操作：在12c环境中创建测试表与索引，通过全表扫描执行SQL并记录基线成本。随后运行SQL Tuning Advisor生成任务，并展示了工具内置的“验证”步骤——它对比了原始执行计划与推荐SQL PROFILE计划的关键指标。测试结果极具说服力：使用SQL PROFILE后，缓冲区获取（Buffer Gets）从1470锐减至3，提升达99.79%，同时CPU时间与耗时也几乎归零，证明索引扫描方案远优于全表扫描。 这篇文章的实用价值在于，它提供了一个无需全面部署即可在session级别评估SQL PROFILE效果的清晰范式，帮助DBA在追求性能与保障稳定性之间找到平衡点。
HBase Block Cache实现机制分析
这篇讲的是HBase的Block Cache——RegionServer中负责读缓存的核心模块。它从HBase的读写内存分工切入，解释了读请求如何依次查询Memstore、BlockCache和磁盘，并最终将结果缓存的完整链路。 文章重点剖析了BlockCache的“三级缓存”设计：新访问的Block放入Single队列，多次访问则升至Multi队列，而Meta表等关键数据则放入InMemory队列。这种分级策略既保护了关键元数据，又避免了全表扫描对热点数据的冲击。默认的内存分配比例（Single:Multi:InMemory = 0.25:0.50:0.25）和LRU淘汰策略，是其在内存限制下平衡命中率的关键。 作者还深入到了HBase 0.94.1的源码层面，以`LruBlockCache`类为例，展示了缓存Block时的类型判定逻辑，以及触发后台淘汰线程`EvictionThread`的阈值条件。从整体内存布局到具体的优先级队列实现，文章清晰地拆解了HBase在保证高并发读性能时，所采用的这套精巧的缓存管理思路。
HBase如何合理设置客户端Write Buffer
这篇技术博客从实战角度出发，深入剖析了HBase客户端的Write Buffer机制。文章指出，每次单条Put都会引发一次网络往返（RTT），在数据量小、RTT较高的场景下，这个开销会成为性能瓶颈。通过开启Write Buffer进行批量提交，可以将N次RTT降低为一次，从而显著提升写入吞吐。 作者没有停留在概念介绍，而是结合HBase源码，揭示了底层实现细节：客户端会先按Region Server将Put对象分组打包，再统一发起RPC请求。文章还详细拆解了Write Buffer的触发条件（如autoFlush设置、缓冲区满），并给出了单个Put对象大小的预估公式 `((50~60) + L1) * N + L2 bytes`，帮助开发者根据自身数据特征（列数N、RowKey长度L1、Value长度L2）来预估并合理配置缓冲区大小。 最终，文章清晰地划分了适用场景：对于KB级别的小数据写入，调整Write Buffer收益明显；而对于MB级别的大记录，由于数据传输时间占主导，则不建议依赖此机制。这种从原理到源码再到实践的分析路径，为调优HBase写入性能提供了扎实的依据。
利用MySQL触发器高性能造数据
这篇讲的是一个关于MySQL触发器的有趣发现：它通常只用来做简单的表间更新，但有人用它在批量生成测试数据方面取得了意想不到的高性能效果。 文章作者首先用存储过程作为基准方案，在单线程下为一张包含1000万行记录的表造数据，耗时8分20秒，相当于每秒插入约2万条记录。这个速度本身已经不错。 但作者想测试触发器是否能做得更好。这里有个小限制：MySQL触发器不支持对同一张表进行自我插入，所以他额外创建了一张中转表tb3。核心方案是，为tb3创建一个`AFTER INSERT`触发器，当向tb3插入一条记录时，触发器会立即在目标表tb2中循环插入1000万条随机数据。 最终结果很亮眼：整个过程耗时5分14秒，相当于每秒插入超过3万条记录，比纯存储过程方案的速度提升了约60%。作者用“很HAPPY”来形容这个结果，因为通过一个简单的触发器设计，就显著优化了数据生成的吞吐量，为需要快速填充测试环境的场景提供了一个高效思路。
数据文件的CREATION_TIME来源和算法
这篇文章深入剖析了Oracle数据库中`CREATION_TIME`字段的底层存储机制，解答了“数据文件时间戳从何而来”这一问题。作者从`v$datafile.CREATION_TIME`与`v$datafile_header.CREATION_TIME`必须一致才能启动数据库这一现象切入，指出后者的值实际来源于数据文件头块中的`kcvfhcrt`字段。 核心在于，这个十六进制的`kcvfhcrt`值，是Oracle以1988年1月1日00:00:00为基准点，按“每月固定31天”的简化规则，累计计算出的秒数。文章详细演示了双向转换的算法：既如何将一个具体的日期时间（如2011-03-05 05:26:52）拆解计算为对应的十六进制值`0x2c67319c`，也展示了如何通过一系列除法和取模运算，将该十六进制值反向推导为准确的年、月、日、时、分、秒。 这套算法不仅是Oracle内部的一个实现细节，对于需要手动修复或验证数据文件头信息的DBA来说，也是一个非常实用的底层知识。文章通过具体的数值计算实例，将抽象的转换过程清晰地展现了出来。
基于Redis构建系统的经验和教训
这篇文章从实际应用出发，讨论了Redis的优势与局限，并对比了其他海量数据存储方案。作者指出，Redis的有序集合（zset）等丰富数据结构使其在表达业务逻辑时极为高效，特别适合对性能要求高、数据规模可控的场景，比如消息传递系统的收发件箱。 然而，Redis“所有数据必须存放在内存中”的核心设计，直接导致了容量瓶颈和高昂的硬件成本。作者通过计算说明，对于一个百万级用户系统，数据量轻松超过单机内存极限。由此还引发了一系列问题：持久化时fork进程占用双倍内存，Aof日志写盘可能阻塞系统，以及不成熟的主从复制可能因网络抖动产生全量同步，严重消耗带宽。单机架构也迫使开发者在业务逻辑之外，必须额外设计复杂的数据分片方案。 面对海量数据，文章对比了Cassandra、HBase和MongoDB等方案。作者认为纯键值存储（如Cassandra）对结构化数据的表达能力太弱；而像HBase这类系统，其数据模型提供了更有序的组织方式。文章最终提出的观点是：理想的存储方案应当提供基础的有序数据结构，允许开发者通过“实体”加“有序子集”的方式来自然映射业务逻辑，从而在海量数据规模下，实现高效的数据访问与传输。 因此，Redis应定位在小而美的高性能缓存或结构化存储层，而非追求海量数据的存储目标。
ORACEL RAC 字符集
这篇讲的是在Oracle RAC环境下修改数据库字符集，一个容易“踩坑”的实操过程。 作者从一个ZHS16GBK字符集的10g RAC环境出发，目标是将其变更为UTF8。文章核心记录的并非一帆风顺的步骤，而是在执行过程中遇到的典型问题：当尝试直接执行 `alter database character set` 命令时，数据库报出了 `ORA-12720` 错误，提示需要独占模式。这正是RAC环境下修改字符集的关键陷阱。 为解决此问题，作者展示了完整的排查与操作流程：首先需要停止一个节点实例，然后修改 `cluster_database` 参数将集群模式临时改为 `false`，并以独占（`EXCLUSIVE`）模式启动数据库。在确保单节点独占访问后，方才成功执行了字符集变更命令。文章还提到了一个细节操作：手动更新 `props$` 表以同步国家字符集信息，这对于保持数据字典一致性至关重要。最后，再将参数改回集群模式并重启集群。 整个操作对生产环境风险极高，文章通过真实报错和步骤复现，清晰地揭示了RAC架构下字符集变更的特殊限制与必备前提。对于需要执行此操作的DBA来说，这份记录提示了务必在维护窗口内进行、并提前备份的要点。
MySQL5.6.7-rc index condition pushdown代码解读
这篇讲的是MySQL 5.6.7-rc版本中Index Condition Pushdown（ICP）特性的源码探索之旅。作者对ICP很感兴趣，于是决定跟踪代码，一探究竟。 文章首先通过对比不同索引结构下的`EXPLAIN`执行计划，直观展示了ICP的效果。在单一字段索引下，查询需要先通过索引找到主键，回表取完整数据，再用其他条件过滤。而创建了`(name, info)`联合索引后，像`info like '%1'`这样的条件，能在索引层就先被过滤掉，从而减少了回表次数，执行计划里也不再出现“Using where”。 最关键的“真相”在代码里。作者一路跟下去，找到了存储引擎层比较WHERE条件的位置，并直接给出了函数调用栈：从`row_search_for_mysql`开始，通过`row_search_idx_cond_check`，最终调用到`innobase_index_cond`执行条件判断。这个调用链清晰地揭示了ICP是如何在InnoDB引擎内部、在通过二级索引读取记录时，提前将不满足条件的数据过滤掉的，避免了不必要的回表操作，这正是该特性的巧妙之处。
深入浅出INNODB MVCC机制与原理
这篇讲的是MySQL InnoDB存储引擎中一个核心且容易让人混淆的机制——多版本并发控制。作者从数据库事务的基本概念（如隔离性、锁）切入，清晰地引出了MVCC存在的必要性：在保证数据一致性的同时，最大化提升并发处理能力。 文章的精华在于对MVCC实现原理的拆解。它没有停留在常见的“创建时间与删除时间”的简化描述上，而是直接指出了这个广为流传的说法存在两处不准确。作者通过`SHOW ENGINE INNODB STATUS`等命令，详细解释了InnoDB在行数据中实际隐藏的三个关键字段：`DB_TRX_ID`（事务ID）、`DB_ROLL_PTR`（回滚指针）和`DB_ROW_ID`（行ID），并阐明了它们各自的职责。 更进一步，文章通过具体的事务ID示例，图形化地演示了在“可重复读”隔离级别下，一条SQL查询如何根据这三个字段和“Read View”（读视图）来判断数据的可见性，从而实现“读不阻塞写，写不阻塞读”的高效并发。它特别纠正了“删除”操作的误解，指出MVCC中的“删除”仅是标记，真正的物理删除发生在后续清理阶段。 这篇文不仅梳理了基础知识，更致力于帮读者建立对InnoDB MVCC机制更准确、更底层的理解框架，对于想弄明白“快照读”背后究竟发生了什么的开发者来说，提供了非常扎实的技术解析。
mysql系统变量专题学习
这篇讲的是MySQL系统变量的深度解析。作者发现官方中文文档简略，网络资料零散，于是花了两周时间，结合查阅和亲手测试，系统梳理了这些决定MySQL配置与性能的关键变量。 文章没有停留在罗列定义上，而是深入到每个变量的作用域（全局或会话）和值域，并辅以实战配置与效果演示。比如，详细讲解了如何启用和解读慢查询日志（`log_slow_queries`），从而捕捉性能瓶颈；剖析了`concurrent_insert`不同取值下，MyISAM表读写并发行为的差异；还澄清了`log_warnings`等较少被讨论的变量。 作者通过具体的案例（如一条查询被记录进慢日志的完整输出），让抽象的变量配置变得可见、可验证。这对于需要调优MySQL性能、理解其内部机制，或是寻找一份可靠变量参考手册的开发者和DBA来说，提供了一份扎实、可操作的指南。
为什么字段尽可能用NOT NULL，而不是NULL
这篇探讨的是MySQL数据库字段类型选择的核心争议：为什么推荐使用NOT NULL而非NULL。作者从常见的优化建议切入，指出许多文章只抛出结论却未解释缘由，于是从技术细节上深入对比了两者的关键差异。 首先，文章澄清了一个普遍误解：很多人误以为NOT NULL会增加存储空间，实际上恰恰相反——NULL列需要额外一个字节作为是否为空的标志位，导致存储开销上升。根据MySQL官方文档，NULL列在行中占用更多空间，尤其在MyISAM表中，每个NULL列甚至引入比特级的额外负担，向上取整到字节级别。 更重要的差异体现在查询优化层面。MySQL对可空列的处理更为复杂，难以高效进行索引统计和值比较。例如，可空列
InnODB和MyISAM索引统计集合
这篇讲的是MySQL优化器如何收集和使用索引统计信息来做出查询决策。作者从`myisam_stats_method`变量入手，详细解释了InnoDB和MyISAM如何统计“平均数值组”——即拥有相同索引键值的平均行数。 关键点在于，这个平均数值组越小，说明索引的区分度（Cardinality）越高，优化器就越倾向于使用它。文章通过一个实例直观展示了这一点：一张千行表的主键Cardinality为966，计算出的平均数值组约为1.04，意味着每个主键值平均只指向约1行数据，索引效率很高。 文章的重点对比在于两种存储引擎处理NULL值的策略差异。通过`NULLS_EQUAL`、`NULLS_UNEQUAL`和`NULLS_IGNORED`三种统计方法，优化器会对NULL值有不同的“看法”，从而影响平均数值组的计算结果。例如，`NULLS_EQUAL`会把所有NULL视为相同，这在NULL值非常多的情况下会大幅降低Cardinality，导致优化器错误地放弃本应使用的索引。而`NULLS_UNEQUAL`（MyISAM的默认策略）则将每个NULL视为独立的组，更适合NULL值不占主导的场景。 理解这些统计信息的收集机制，能帮助我们更清晰地认识为什么`Cardinality`值越大、索引通常越好，并在设计表结构或排查索引失效问题时，考虑到NULL值分布可能带来的影响。
Redis命令行操作指南
这篇讲的是Redis命令行操作的全面指南。作者从连接数据库、基本键操作出发，系统梳理了对String、List、Set、Zset（有序集合）、Hash这五种核心数据类型的所有常用命令。 它不只是罗列，而是结合了具体的场景。例如，SET/GET用于基础的键值存取，SADD/SMEMBERS用于集合成员的增减与遍历，ZADD/ZRANGE则用于需要按分数排序的场景。文章还涵盖了持久化（如SAVE/BGSAVE）和远程服务器控制（如INFO/MONITOR）等运维命令。 对于Redis使用者来说，这就像一份随时可查的“命令字典”，将官方文档中分散的命令按功能和数据类型组织起来，提供了清晰的参照。无论是初学者熟悉接口，还是开发者日常查阅特定命令的用法，都能从中快速找到答案。
MySQL vs MariaDB vs Percona 之TPCC性能测试
这篇测评比较了MySQL、MariaDB和Percona在TPCC基准测试中的性能表现。作者搭建了统一的硬件环境，通过自动化脚本运行了严格的1000仓库规模测试，重点对比了不同版本（如MySQL 5.6、Percona 5.5/5.6、MariaDB 5.5）以及关键配置差异（如独享表空间、InnoDB Buffer Pool实例数）对性能的影响。 测试结果显示，Percona 5.6（配置为独享表空间且Buffer Pool实例数为1）取得了最高的TpmC（每分钟事务数），性能优势显著。同时，测试观察到一个趋势：在测试的线程数范围内，并发线程数增加通常能带来更高的TpmC效率。相比之下，文章也指出本次测试并未深入涵盖各数据库版本宣称的所有新特性。 对于需要高事务处理能力的OLTP场景，文章数据表明Percona 5.6是一个值得考虑的高性能选项。
那些在11gR2中可能惹祸的新特性，一张列表帮助你摆脱升级11gR2带来的烦恼
这篇讲的是从Oracle 10g/9i升级到11gR2时，可能因新特性默认启用而“惹祸”的那些事儿。作者指出，像自适应游标共享（Adaptive Cursor Sharing）、自动串行直接路径读（Automatic Serial Direct Path Read）、延迟段创建（Deferred Segment Creation）以及GC相关的新特性等，在实际中可能并不适合许多国产应用，会给原本稳定的系统带来执行计划波动等不确定风险。 文章的核心是一份可直接操作的“排雷清单”。作者汇总了一系列优化器和其他相关特性的隐藏参数，提供了一套通过设置参数来选择性禁用这些新特性的方法。其背后的逻辑很务实：如果你的应用没有条件或时间对这些新特性进行充分测试，不如主动禁用它们，让数据库在11gR2的架构上退回到类似于10gR2（10.2.0.4）的稳定行为模式。 作者也解释了“禁用新特性是否还有升级必要”的疑问。他强调，这并非全盘否定，而是给出了一份可选的选项列表。熟悉且已验证的特性可以保留，不熟悉的则可以选择关闭，从而在享受新版本其他益处的同时，规避因未经测试的优化器行为变更带来的潜在故障。对于那些需要手动开启才会生效的特性（如Flashback Archive），则不受此列表影响。
大于2GB的Listener.log和运行超过198天的主机上的Oracle实例
这篇讲的是Oracle DBA圈里流传已久的两个“传说”及其在当代的真相。 一个是关于Listener.log日志文件不能超过2GB的限制。作者追溯其根源，指出这在早年32位操作系统与文件系统（如Solaris 2.6、早期Linux）时代确实是铁律，但对如今主流的64位系统已成过去式。他通过实际演示，在64位Linux上让Listener.log增长至3GB以上，并依然成功建立新连接，直接证伪了这一“信仰”。同时，他从系统调用层面解释了监听器进程使用O_APPEND标志位追加写入，性能并不会因文件过大而下降。 另一个则是主机运行超过198天会导致Oracle实例故障的传闻。作者澄清，这特指Oracle 10.2.0.1版本的一个已知BUG，会导致OCI客户端CPU空转。该问题在后续的10.2.0.2补丁集中早已修复。他提到，这个因特定版本与超长运行时间偶合的BUG因其戏剧性而令人印象深刻，以至于多年后在部分运维场景中仍被当作经验传播。 文章的核心结论是，这两个基于特定历史条件产生的“最佳实践”，在硬件与软件都已迭代的今天应当被更新认知，尽管定期清理日志等习惯依然值得推荐。作者通过技术细节与版本历史，为读者梳理了从“真理”到“传说”的演变脉络。
低成本和高性能MySQL云数据的架构探索
这篇讲的是阿里核心系统数据库团队如何从零打造一个名为UMP的MySQL云服务平台，来同时解决大规模MySQL集群面临的成本与性能难题。 背景是淘宝这样的企业有数千台MySQL服务器，直接扩展成本高昂。他们的UMP系统目标很明确：让开发者能方便地申请和使用资源，而由平台透明地处理主从热备、读写分离、分库分表等复杂运维工作。核心方案是在一台物理机上运行多个MySQL实例以降低成本，并实现资源的弹性隔离与分配。 他们最初的方案基于MySQL-Proxy，但很快发现了它的多线程模型缺陷、功能扩展困难以及社区不活跃等问题。于是，团队果断选择用Erlang语言重写了整个Proxy层。Erlang轻量级的“绿进程”和OTP框架，为他们提供了高并发、高容错且易于热部署的编程模型，完美契合了云服务的需求。 最终的UMP系统架构包含Controller、Proxy、Agent等多个角色，通过RabbitMQ和ZooKeeper协同工作，构成了一个完整的、可伸缩的云数据库服务。文中还透露，这个系统已经在天猫聚石塔等平台落地，为电商业务提供着安全可靠的数据云服务。
从load data引发的死锁说起
这篇讲的是一个线上数据分析项目中，因频繁使用LOAD DATA语句向InnoDB表导入数据而引发的死锁问题。作者从实际线上故障出发，详细拆解了死锁产生的典型场景：当多个客户端并发执行LOAD DATA时，由于该操作会自动使用事务并持有元数据锁，若并发事务的加锁顺序不一致，极易触发死锁循环。 文章重点剖析了根因，指出LOAD DATA在事务中会隐式开启事务并在结束时提交，多个并发导入流在等待彼此释放行锁时形成死锁。处理方案上，作者结合锁等待关系图进行了分析，并探讨了如调整事务隔离级别、控制并发导入粒度等应对策略。最后，文章还延伸讨论了LOAD DATA的事务特性、InnoDB的元数据锁机制以及如何通过监控锁等待关系来快速定位类似问题，为处理高并发数据导入场景下的锁冲突提供了具体思路。
固态硬盘知识汇总
这篇梳理了固态硬盘（SSD）在各种外部环境下的性能与寿命表现，核心聚焦于温度、震动、电源稳定性等现实因素如何影响其可靠性。作者从实验室数据和长期使用案例出发，对比了不同主控与闪存颗粒在高温或供电不稳时的表现差异，并具体解释了为什么持续高温会加速闪存老化，而异常断电可能引发FTL表损坏。 文章不仅列出了问题，更给出了应对场景的实用建议，比如为高性能SSD搭配散热片，或为关键数据盘配备UPS不间断电源。它特别指出，消费级与企业级SSD在环境耐受性上的设计取舍，帮助读者根据自身使用条件（是作为系统盘、游戏盘，还是NAS缓存）做出更合适的选择。这种将理论与具体硬件特性、用户场景紧密结合的写法，让“知识汇总”真正落到了实处。