MySQL索引之主键索引
这篇文章厘清了MySQL中主键索引和辅助索引的几处关键区别。 作者从两者的定义出发，指出主键索引是唯一标识记录、不可为NULL的索引，而辅助索引则包括唯一索引和非唯一索引。核心对比在于不同存储引擎下的行为差异：在MyISAM中，一个不允许NULL的唯一索引与主键索引本质相同，性能也相当；但在InnoDB中，主键索引即聚集索引，而辅助索引（无论是否唯一）存储的都是指向主键的指针，因此通过辅助索引查找数据需要额外的转换步骤。 文章用一组测试数据直观地展示了性能区别：在100万行数据的MyISAM表上，普通索引的随机检索效率比主键索引慢了30%以上；而在InnoDB表上，唯一索引比主键索引慢约9%，普通索引的差距则扩大到50%以上。这清楚地说明，理解这些索引机制对于InnoDB的表结构设计与查询优化至关重要。
MySQL运行中被改权限测试
这篇讲的是一个真实的线上踩坑经历。作者的一位朋友遭遇了数据库目录权限被运维人员误改为 root 的紧急情况。为了弄清后果，作者特意搭建了 MySQL 主从环境进行测试。 实验中，将主库目录权限改为 root 后，在触发日志切换（flush logs）之前，主库的数据写入和主从复制似乎一切正常。但关键问题在日志切换时暴露：主库因无权创建新 binlog 文件而报错，而从库虽然收到了新的日志文件名，却无法获取到实际日志内容，导致复制中断。 这个现象有点反直觉：权限错误并未立刻阻塞所有数据操作，却为数据同步埋下了一颗定时炸弹。文章的结论很明确：一旦发生这种情况，主库的数据是最全的，但主从已经失同步。作者最后还附上了修复思路和关于这或许是 MySQL 一个“诡异”行为的思考。
Spark的性能调优
这篇文章从实战经验出发，汇总了Spark性能调优的多个关键方向。内容不仅涵盖基础配置，更深入到应用代码设计与任务执行策略。 开篇即点明，调优的第一步往往从数据序列化开始，对比了默认的Java序列化与更快更紧凑的Kryo方案。紧接着是内存管理，文章给出了具体的检测方法（如使用UI或SizeEstimator）和优化建议（如启用压缩指针）。GC调优部分尤为实用，解释了默认内存分配比例、Eden区设置，并分享了如何避免因大量对象创建导致的“GC overhead limit exceeded”错误。 对于影响性能的关键因素，文章详细阐述了并行度、Reduce Task内存使用以及Shuffle的优化。例如，通过广播变量减少大表shuffle是一个经典模式。数据本地性的五个层级及其调度策略也被清晰说明。文件存储与读取优化（如使用Parquet列存格式）和Speculation（推测执行）机制也被纳入考量。 最后，文章强调了合理设置分区数和减少不必要Shuffle的重要性，并给出了具体的代码示例指引。整篇文章既包含JVM级别的参数调整，也涉及Spark应用层的数据结构设计与API选择（如prefetchByKey vs groupByKey），是一份从理论公式到实战经验的综合性调优指南。
MySQL不同复制模式下，如何忽略某些binlog事件
当MySQL主从复制因主键冲突、数据不存在等错误而中断时，如何快速跳过问题事件让复制继续？这篇技术博客给出了清晰的解决方案。 文章首先区分了两种场景。在未启用GTID的传统模式下，方法相对直接：通过`STOP SLAVE`、`SET SQL_SLAVE_SKIP_COUNTER=N`、`START SLAVE`三步，即可跳过指定数量的事件。但在启用GTID的现代架构中，操作则更为精细，需要手动计算并设置`GTID_PURGED`来“抹掉”导致错误的那个事务，让复制从下一个事务恢复。 此外，文章还推荐了Percona Toolkit中的`pt-slave-restart`工具，它能自动监控并忽略特定错误（如1062错误或匹配指定文本的错误），重启复制进程，是DBA手中非常便捷的利器。 整体来看，文章从手动命令到自动化工具，覆盖了处理复制错误的多种思路，对比了不同模式下的操作差异与工具带来的便利性，为数据库运维人员提供了实战性很强的参考指南。
RDS MySQL参数调优最佳实践
这篇讲的是RDS MySQL用户常困惑的参数调优问题。作者从实际场景出发，首先明确了哪些参数由产品规格或数据安全决定无法修改，比如内存、连接数和主备同步相关参数。这解决了用户“能不能改”的首要疑惑。 文章的核心价值在于，它清晰地指出绝大部分参数已由专业团队优化，仅需针对特殊场景微调。随后，作者深入剖析了open_files_limit、back_log、innodb_autoinc_lock_mode等几个关键参数：逐一说明其作用、设置不当会引发的典型错误现象（如“Too many open files”、连接超时或死锁），并给出了具体的调整建议和原理。 此外，文章还介绍了几个RDS特有的实用参数，例如控制临时磁盘空间的rds_max_tmp_disk_space和用于保护数据库的rds_threads_running_high_watermark，让读者能按需应用。整体而言，这篇文章并非泛泛而谈，而是提供了从“能否修改”到“为何调整”再到“如何调整”的完整实践路径，能帮助用户避免性能陷阱。
MySQL B+树索引和哈希索引的区别
这篇讲的是 MySQL 里 B+树索引和哈希索引这两种常用数据结构的根本区别。作者从它们的数据结构图示出发，清晰地揭示了核心差异。 B+树是一个平衡的多叉树，节点间有指针链接，所以它不仅擅长等值查询，也天然支持范围查询、排序以及遵循最左匹配原则的联合索引。而哈希索引通过一次算法运算就能直接定位数据，在等值查询上速度极快，但代价是它破坏了数据的有序性，因此无法用于范围查询、排序和部分模糊查询。 文章还特别指出，只有 MEMORY 引擎能显式创建哈希索引，而 InnoDB 的自适应哈希索引不在此列。同时提醒了哈希索引在数据重复度高时可能遇到的哈希碰撞问题，以及 MEMORY 引擎表重启后数据会丢失的特性。 结论很实用：大多数需要范围查询、排序的通用场景，请坚定地选择 B+树索引。只有在使用 MEMORY 表、数据基数大且仅进行简单等值查询时，哈希索引才是更合适的选择。
实例解析MySQL性能瓶颈排查定位
这是一篇典型的故障排查实战文章。作者从线上MySQL实例负载告警入手，完整记录了从操作系统层面到数据库内部的定位过程。通过`w`、`sar`、`top`、`iotop`等命令，一步步锁定了高负载源于某个MySQL实例严重的磁盘I/O等待。 深入该实例后，发现瓶颈来自一条低效的SQL查询：它通过正序排序后取最大值，导致每次执行都需要全表扫描500多万行数据。作者将其优化为直接倒序排序取首条记录，将执行时间从上百秒降至毫秒级，性能提升显著。文章最后也总结了此类问题的常见成因，如大单次读写、缺少索引或突发流量等。对于需要处理数据库性能问题的开发者来说，这份从现象到根因的清晰排查路径很有参考价值。
SLAVE为什么一直不动了
这篇讲的是MySQL复制延迟中一种“假死”现象的排查。作者从一次延迟超大（超过3小时）但SQL线程却“无事可做”的报警出发，展示了如何一步步定位。 初步检查显示，主从IO和SQL线程都在正常运行，但从`show slave status`看，Relay Log的执行位点（Exec_Master_Log_Pos）却纹丝不动。关键的突破点在于检查主库的Binlog内容。作者发现，从卡住的位点（294959）开始，整个事务是一个巨大的`DELETE`操作——它来自Bacula备份系统的自动清理任务，一次性删除过期数据，事务提交耗时超过2000秒，产生的Binlog数据量接近3.9G，几乎填满了整个Binlog文件。 根因就在于此：这个超大事务在主库执行完毕并生成Binlog后，从库需要将其“重放”一遍。由于事务过于庞大，应用这个DELETE操作本身就需要极长时间，导致复制位点看起来一直“卡住”。文章不仅点明了直接原因，还提醒了这类大事务的潜在危害：除了延迟，还可能长时间锁住数据行，引发连锁的锁等待。 对于通用应用，作者给出的解决方案很务实：在代码层面控制事务粒度，比如每删除几千条记录就提交一次，避免生成这种“一镜到底”的巨型事务。这比直接修改第三方软件的源码更可行。
微博分布式存储作业实现方法
这篇讲的是微博如何在单表60亿条数据的极端场景下，设计分布式存储系统。作者从新兵训练营的实际练习题出发，拆解了社交场景下“查最近微博”和“翻阅用户全部微博”两大核心访问需求，以及由此带来的扩展性、成本与高可用设计挑战。 文章详细讨论了基于用户ID（UID）的范围分片与哈希分片策略，并对比了各自的利弊。重点分享了如何通过“冷热数据分离”来平衡成本与性能：近期数据（如最近10天）采用UID结合权重哈希的方式，均匀分散高并发读取压力；历史数据则按时间维度（如半年）分库，便于管理与冷存储。针对复杂的分页跳转查询，还提出了增加二级索引表等具体的索引设计思路。 文中展示了多个投稿案例，包括一种通过ZooKeeper动态调整分片策略、以灵活应对流量突变的方案。整体思路清晰，从约束条件到具体技术选型层层递进，为处理超大规模社交数据的存储与查询提供了切实可行的架构参考。
如何成为MySQL DBA
这篇文章就像一份路线图，为想进入MySQL DBA领域的朋友清晰地规划了从入门到进阶的学习路径。作者凭借十多年的一线经验，指出不必过分畏惧这个岗位的门槛，并强调了扎实的Linux基础是关键的第一步。 核心内容聚焦于一条明确的DBA学习主线：从理解MySQL版本与启动原理、掌握基础SQL语言，到深入学习复制、备份恢复、压力测试，直至最终能剖析InnoDB的事务与锁机制。作者不仅列出了具体要掌握的技术点，还分享了一些实用建议，比如学习SQL规范时可以请教有经验的前辈。 文章进一步指出了向高级DBA迈进时需要拓展的知识面，包括操作系统层面的IO与内存理解、高可用架构的自主设计以及平台管理能力。最后，作者回归到技术人持续学习的本质，为这条成长之路定下了脚踏实地的基调。
MySql lower_case_table_names迷思
这篇讲的是从Oracle或SQL Server迁移到MySQL时，一个常被忽略的“大小写敏感”坑。作者从实际迁移项目出发，指出纠结`lower_case_table_names`设置的根源在于不同数据库系统的默认行为差异——MySQL在Linux下默认区分大小写。 他给出的实战建议很明确：优先在代码层面统一表名大小写（全大写或全小写），然后再迁移数据库，这样能保持`lower_case_table_names=0`的默认安全设置。如果时间紧张无法修改代码，只能先妥协设置`lower_case_table_names=1`，但务必在项目后期通过开启`general log`逐步排查和修正不规范的SQL。 文章最后强烈呼吁，在制定数据库规范时就该强制统一表名大小写，避免混合写法带来的无尽麻烦。这个观点对于所有需要跨平台迁移或维护规范的团队，都有直接的参考价值。
磁盘空间满了之后MySQL会怎样
当数据库磁盘被撑爆后，MySQL会如何反应？这篇讲的正是这个运维中常见的“车祸现场”。磁盘满后，MySQL将无法写入任何新数据，包括表数据和binlog。不过，由于InnoDB可以先将脏页存放在内存，所以问题不会立刻爆发，只有在涉及binlog写入时，请求才会被阻塞。 文章详细描述了MySQL的后续行为：它会每分钟检查一次磁盘空间，一旦发现可用空间就立即恢复写入；如果连续十分钟仍无空间，则会在日志中记录一条告警。对于处理办法，作者给出了几个具体步骤：及时清理无用文件释放空间；若发现有线程被阻塞，可将其杀掉，等待系统下一轮自动检测后恢复正常；有时一个被阻塞的线程会引发连锁阻塞，处理掉源头线程即可解除整个卡顿。 此外，文章还特别提到了一个例外情况：在执行`REPAIR TABLE`、`OPTIMIZE TABLE`或批量更新索引等操作时，如果磁盘满了，MySQL会将涉及的表标记为崩溃状态并删除临时文件（`ALTER TABLE`操作则会主动放弃并清理）。需要注意的是，若此时mysqld进程意外终止，这些临时文件需要人工删除才能释放空间。整篇文章从现象到原理，再到实操应对，提供了清晰的排查与处理思路。
linux上二进制部署mysql详细步骤(测试环境常用)
这篇讲的是如何在Linux系统上用二进制包快速部署MySQL，特别适合测试环境。作者从实际经历出发，指出rpm安装常出问题、编译安装又太耗时，因此选择了二进制包方案。 文章以MySQL 5.5.42版本为例，详细拆解了从下载、解压、创建用户、初始化数据库到配置权限的全过程。作者特别强调了几个容易踩坑的地方：比如在Ubuntu上安装时，系统可能因缺少libaio1库而报错，导致初始化失败，解决办法是用apt安装该库后重新执行初始化。此外，文章也厘清了CentOS和Ubuntu在自启动目录、socket文件路径等方面的差异。 作者还分享了实用技巧，比如如何设置root密码、通过端口查看服务状态，以及当遇到socket连接错误时，可以尝试通过指定127.0.0.1地址来登录。这些细节让整个部署流程更具操作性，即使不熟悉环境，也能跟着步骤在几分钟内搭好MySQL服务器。
EXPLAIN执行计划中要重点关注哪些要素
这篇讲的是如何快速解读 MySQL EXPLAIN 执行计划，抓住性能优化的关键。对于 DBA 和后端开发者来说，EXPLAIN 是诊断 SQL 性能的必备技能，但面对输出结果中的众多字段，很容易抓不住重点。 文章从实战出发，提炼出了最需要关注的几列信息：type、key、key_len、rows 和 Extra。作者特别详细地梳理了 `type` 字段的取值，将其从最差的 `ALL`（全表扫描）到最好的 `system`（系统表）进行了清晰排序，比如解释了 `index` 类型可以避免回表，`const` 则意味着基于主键的唯一查询。 除了查询类型，文章也点明了其他几个要素的优化含义：`key` 列告诉你是否命中了索引；`rows` 值越小代表预计扫描行数越少，查询越高效；而 `Extra` 中的 `Using filesort` 和 `Using temporary` 则是需要警惕的性能隐患信号。 掌握这几个核心要素，你就能在面对慢查询时，快速从 EXPLAIN 结果中定位到瓶颈所在，为索引优化和查询改写提供明确方向。
Oracle正则表达式使用小结
这篇文章梳理了Oracle数据库从10g开始支持的正则表达式功能。作者将匹配逻辑集中在数据库端，可以避免在中间层处理，从而简化开发。文章概要总结了Oracle中使用正则表达式的核心方法。 内容重点介绍了五个关键的正则表达式函数：REGEXP_LIKE 用于条件过滤，REGEXP_COUNT 能统计模式出现次数，REGEXP_INSTR 可定位首次匹配位置，REGEXP_REPLACE 支持模式替换，REGEXP_SUBSTR 则能提取满足模式的字符串。每个函数都配有清晰的SQL示例。 除了函数用法，文章还梳理了控制匹配行为的选项，比如忽略大小写的“i”、多行模式“m”等，并通过示例解释了不同选项带来的具体差异。此外，文中也列举了如“.”“+”“*”等常见元字符及其含义，为实际编写匹配模式提供了参考。
MySQL索引之聚集索引
如果你曾经困惑过MySQL的InnoDB和MyISAM索引机制到底有何不同，这篇文章提供了一个清晰的对比视角。它聚焦于“聚集索引”这一核心概念，指出在InnoDB的“索引组织表”中，数据的物理存储顺序由主键索引的逻辑顺序直接决定，这使其在范围查询和热点数据读写上效率更高，但离散写入则可能成为短板。相比之下，MyISAM作为“堆组织表”，数据写入顺序与索引无关，虽无聚集索引带来的结构优势，却也避免了离散更新时的性能损耗。 文章进一步剖析了InnoDB表中聚集索引的唯一性及其选择规则：优先显式主键，其次首个非空唯一索引，最后回退到内置ROWID。这意味着聚集索引的键值逻辑地组织了整张表。通过对比IOT（索引组织表）与HOT（堆组织表）在碎片产生、查询开销等方面的优劣，文章实际上是在指导读者根据自身的数据写入模式和查询需求，来审慎选择表引擎和设计主键，从而优化数据库性能。
解读EXPLAIN执行计划中的key_len
这篇文章讲的是MySQL中EXPLAIN执行计划的key_len列该如何解读，它如何帮助你判断联合索引的实际使用情况。 作者指出，key_len代表查询中使用的索引字节数，其计算涉及几个关键因素：索引列的基础类型字节数（如INT为4字节，BIGINT为8字节）、字符串列的字符集（例如UTF8下每个字符占3字节）、该列是否允许NULL值（需额外增加1字节），以及是否为变长类型（如VARCHAR需额外增加2字节）。 文章通过一个清晰的表格列举了不同列定义下的具体计算示例，例如`int not null`的key_len为4，而允许NULL的`varchar(30) utf8`则为`30*3 + 2 + 1 = 93`。这能让你直观看到各种约束对索引长度的影响。 最后作者强调了一个重要细节：key_len仅统计了WHERE条件过滤所使用的索引列，并不包含ORDER BY或GROUP BY部分用到的索引。因此，在分析如`WHERE c1=? AND c2=? ORDER BY c1`的查询计划时，即便有联合索引，其key_len值也可能小于索引总长度，这对于理解查询优化器行为很有帮助。
清官谈mysql中utf8和utf8mb4区别
这篇文章对比了MySQL中两种常见的字符编码：utf8与utf8mb4。作者从实际存储问题出发，解释了核心差异：MySQL的utf8编码最大仅支持3个字节的UTF-8字符，因此无法存储Emoji表情、部分生僻汉字等占用4个字节的Unicode字符，插入时可能导致异常。而utf8mb4作为其超集，专门用于兼容这类四字节字符。 文章进一步追溯了问题根源，指出这与MySQL早期设计时Unicode尚未扩展辅助平面有关，当时的utf8被限制为最多3个字节。作者建议，尽管utf8在多数情况下足够且更节省空间，但为了更好的兼容性和前瞻性，应始终优先使用utf8mb4字符集（需MySQL 5.5.3以上版本）。同时，他提到使用utf8mb4时，对于CHAR类型数据会额外消耗空间，官方推荐使用VARCHAR类型进行替代。
MySQL索引原理与慢查询优化
这篇讲的是如何从原理层面理解MySQL索引，并将其应用于实际的慢查询优化。作者从“查询效率”这个基本需求出发，首先用字典类比引出索引概念，然后深入讲解了数据库为平衡磁盘IO成本所选择的数据结构——B+树。文章详细剖析了B+树的节点结构、查找过程以及高度可控的优势，解释了为什么索引字段要尽量小，以及复合索引的“最左匹配”原则是如何从B+树结构推导出来的。 在原理部分之后，文章给出了几条非常实用的建索引原则，比如索引列不能参与计算、尽量扩展而非新建索引等。最后，它提供了一套慢查询优化的基本步骤，并强调了`explain`命令中`rows`指标的核心作用。整篇文章将底层的数据结构原理与上层的SQL优化实践紧密串联，帮助读者不仅知道“怎么做”，更理解“为什么”。
[MySQL异常恢复]无主键情况下innodb数据恢复
这篇讲的是，当MySQL InnoDB数据库发生异常需要恢复时，一个常见的“坑”：通常恢复工具都假定表必须有主键或唯一索引，否则就无从下手。文章指出这其实不是绝对的死路。 核心在于，即便没有用户定义的索引，InnoDB也为每个表维护了一个内部的`index_id`。这个ID贯穿数据文件，是定位数据页的线索。作者从这个突破点出发，详细演示了如何在无主键的场景下进行数据恢复。 他通过创建一个真实的无主键表，并插入了32万余行数据来模拟故障现场。随后，文章逐步展示了使用工具解析ibdata1系统表空间文件的过程。关键步骤在于，如何从解析结果中筛选出对应表的`index_id`，并以此为线索重组数据。 这种方法为那些因设计疏忽或特殊原因未设主键的数据库，在遭遇崩溃时提供了一条可行的抢救路径，避免了数据彻底丢失的风险。