标签：MyISAM

共 12 篇相关文章

IT 累计浏览 6,233

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值分布可能带来的影响。

IT 累计浏览 3,847

用insert delayed减少阻塞时间

这篇讲的是如何解决高并发场景下，频繁 `INSERT` 操作导致的数据库阻塞问题。作者从一个非常具体的痛点出发：在消息队列、日志收集等高吞吐写入场景中，频繁的 `INSERT` 操作经常会互相阻塞，导致写入延迟飙升。为了解决这个“堵”的问题，文章推荐了一个经典的优化方案：使用 `INSERT DELAYED`。这个语句是 MySQL 提供的一种特殊写法，它告诉数据库：“你不必立刻把这个数据写进磁盘，先把它放到队列里，马上告诉我客户端已经处理了”。这样，数据库就能立刻释放锁和连接，去处理下一条请求，从而将原本同步、串行的阻塞过程，变成了异步、批量的处理。文章详细介绍了它的使用语法，并对比了普通 `INSERT`，说明它在哪些具体场景（如写入日志、临时数据缓存）下效果最好。当然，文章也指出了这个方案的适用边界，比如无法保证数据立即落盘，因此不适合对实时性要求极高的金融交易等场景。总的来说，它为受阻塞问题困扰的开发者提供了一个立竿见影、且原理清晰的优化思路。

IT 累计浏览 4,106

MySQL 备份和其恢复机制原理简述

这篇讲的是MySQL数据安全体系中两个核心操作——备份与恢复的底层原理。文章从备份的必要性切入，重点对比了逻辑备份与物理备份这两种主流机制。作者指出，逻辑备份（如使用mysqldump）实质上是生成可读的SQL语句，它轻便灵活，适合小型数据库或跨版本迁移，但恢复时速度较慢。而物理备份（如使用xtrabackup）则是直接拷贝数据文件，恢复速度快，对大型数据库更友好，不过操作相对复杂。文章接着深入解析了恢复机制，特别是基于二进制日志（binlog）的时间点恢复（Point-in-Time Recovery）是如何工作的。通过将全量物理备份与持续的增量binlog相结合，可以精确还原到故障前的任意时刻，这对于生产环境避免数据丢失至关重要。作者没有停留在概念对比，而是结合了具体工具的实现思路，让读者能清晰地看到从“备份文件”到“数据复原”的完整路径。文章最后落脚于如何根据数据库规模、业务容忍度及恢复目标（RPO/RTO）来选择合适的策略，为实际运维工作提供了清晰的决策依据。

IT 累计浏览 2,645

mysql的数据压缩性能对比

这篇讲的是MySQL中几种常用压缩算法的实际性能对比。作者从生产环境常见的存储和带宽压力出发，重点测试了Zlib（默认选项）、LZ4和Zstd这三种压缩方案。文章通过具体的基准测试，清晰地展示了它们的核心差异：Zlib压缩率最高，但CPU开销也最大；LZ4则走了另一条路，它几乎不牺牲压缩速度，解压速度极快，但压缩率相对较低；而Zstd在两者间找到了一个不错的平衡点。测试数据表明，在典型的OLTP负载下，使用LZ4能将CPU使用率降低约15%，同时写入吞吐量提升明显，非常适合高并发、对延迟敏感的业务场景。相比之下，Zstd在压缩率上优于LZ4，解压速度依然很快，为需要兼顾存储节省与性能的场景提供了新选择。结论很明确：没有“最好”的算法，只有“最合适”的场景。如果业务是CPU密集型或对吞吐要求极高，LZ4是优选；若需要节省磁盘空间，尤其是针对历史数据或归档场景，Zstd的平衡性让它比Zlib更值得考虑。

IT 累计浏览 3,796

MyISAM和InnoDB两种“引擎”的区别

这篇讲的是MySQL里最经典的两种存储引擎——MyISAM和InnoDB的对比。作者从“存储引擎到底是什么”这个基础概念切入，直接拆解了两者在底层设计上的核心差异。关键区别包括事务支持、锁的粒度（表锁 vs 行锁）、外键约束以及崩溃恢复能力。文章还特别提到了一个容易被忽略的细节：在旧版MySQL中，MyISAM其实是默认引擎，而InnoDB后来居上成为主流，这背后是业务对数据安全性和并发性能要求不断提升的体现。具体到场景选择，文章给出了很清晰的结论：如果你的应用是读多写少、对事务完整性要求不高（比如日志或统计表），MyISAM的简单高效可能更有优势；但凡是涉及订单、用户等需要事务、行级锁和高并发写入的核心业务，InnoDB几乎是必选项。理解这些差异，能帮助开发者在设计数据库表时做出更合理的技术选型。

IT 累计浏览 4,995

详解MyISAM Key Cache(前篇)

这篇讲的是MySQL中MyISAM存储引擎的关键缓存机制。作者从MyISAM Key Cache的一般工作原理入手，逐步拆解了其核心的Mid-point Insertion Strategy——这个策略如何将热数据与冷数据分开管理，从而在有限的缓存空间里最大化数据命中率。文章接着深入到了实际运维层面，详细解释了如何通过`SHOW STATUS`查看Key Cache的各项状态指标，以及如何通过`SET GLOBAL`或配置文件来调整参数，完成缓存池的大小设定与实例分配。最后还梳理了相关的管理命令。整体上，这是一篇面向需要理解或调优MyISAM性能的开发与DBA的实用指南，它把一个常被忽视的底层组件讲得清晰透彻。

IT 累计浏览 2,792

小心对待query_cache_size

这篇文章讨论的是MySQL中一个曾经备受推崇的优化参数——query_cache_size。它从早期MyISAM引擎时代说起，那时开启查询缓存对加速读操作效果显著，因此成为DBA调优的常见手段。作者接着指出了这个参数随着时间推移暴露出的严重问题。核心在于，当表数据发生任何更新（包括INSERT、UPDATE、DELETE），该表相关的所有缓存查询都会被强制失效，这在高并发写入场景下会造成频繁的缓存刷新，引发锁竞争，反而导致性能下降。更关键的是，它无法有效利用多核CPU，且优化器的改进使得在现代硬件和InnoDB引擎下，其收益微乎其微。文章的落脚点在于，MySQL 8.0版本已正式移除此参数。这提醒我们，许多经典优化策略需要随技术栈的演进重新审视。理解query_cache_size从“神器”到“弃子”的完整故事，能帮助我们更好地进行MySQL性能诊断，并做出更贴近当前实践的数据库设计与调优决策。

IT 累计浏览 1,876

MySQL修改库名

这篇讲的是在MyISAM引擎下如何通过最直接的方式修改MySQL库名。操作其实非常简单粗暴：直接停掉MySQL服务，然后找到DATA目录，把对应的库名文件夹重命名即可。对于MyISAM表来说，因为表结构和数据文件（.MYD和.MYI）完全依赖于目录结构，这种物理层面的修改是有效且快速的。文章隐含了一个重要对比：这种“移花接木”的方法之所以可行，完全是因为MyISAM的存储机制。如果你用的是InnoDB，事情就复杂得多了——因为InnoDB的表空间管理、数据字典以及可能存在的系统表（如ibdata1）都绑定了库名，直接改文件夹会导致数据库无法识别。这也侧面说明了为什么在现代MySQL应用中，官方更推荐使用ALTER DATABASE RENAME或专门的工具来处理库名变更，尤其是在涉及InnoDB引擎或生产环境时。所以，这篇文章更像一个特定场景下的“小窍门”分享，适合那些还在使用MyISAM引擎、需要快速调整库名结构的运维或开发人员。它清晰地指出了方法与引擎类型的强关联，避免读者在InnoDB环境下盲目操作，引发数据访问故障。

IT 累计浏览 4,026

合理使用MySQL的Limit进行分页

这篇讲的是如何通过合理使用MySQL的LIMIT子句来优化分页查询，避免性能陷阱。作者从一位开发者遇到的数据库查询变慢的案例切入，对方的单表数据量已超过2G，且仍在使用效率低下的MyISAM引擎。文章核心剖析了“大偏移量LIMIT”这一常见分页写法的性能瓶颈。当使用`LIMIT 1000000, 10`这样的语句时，数据库需要扫描并丢弃前一百万行数据，仅为了返回最后10行，这会导致巨大的IO和CPU开销。作者明确指出这种写法在数据量增长后会迅速成为系统拖累。针对问题，文章给出了具体的优化策略：一是通过添加索引并确保查询能利用覆盖索引来减少回表；二是更推荐采用基于索引列的“书签式”分页，例如记住上一页最后一条记录的ID，改用`WHERE id > last_id LIMIT 10`的方式，使数据库能直接通过索引定位，极大提升查询效率。文章最后强调，在高并发或大数据量的业务场景下，提前规划和优化分页方式至关重要，盲目依赖简单LIMIT会埋下严重的性能隐患。

IT 累计浏览 3,618

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调整通常能带来更直接的收益。对于正在纠结如何选择或配置存储引擎的开发者来说，这些从实践中总结出的记录提供了非常具体的参考。

IT 累计浏览 3,726

MyISAM和InnoDB的插入性能测试

这篇评测从一个实际的测试表结构出发，对MySQL中两种经典存储引擎——MyISAM与InnoDB——的插入性能进行了硬核实测。文章没有停留在理论特性对比上，而是通过构建具体的测试用例，量化了它们在批量插入与单条插入场景下的性能差距。测试结果揭示了两者截然不同的设计取向：MyISAM凭借其非事务性的简单结构，在纯插入速度上展现出了明显优势，尤其在大批量数据导入时效率更高。而InnoDB由于需要维护事务日志、多版本并发控制等复杂机制，插入时会承担额外的开销，因此在同等条件下速度稍逊。但文章并未就此止步，而是进一步点明了性能差异背后的技术权衡。MyISAM的“快”是以牺牲事务安全与崩溃恢复能力为代价的，它更适合读密集或对数据一致性要求不高的场景，如日志表或临时表。而InnoDB的“慢”换来的是完整的事务支持、行级锁与强大的数据完整性，是绝大多数OLTP业务场景下的必然选择。这篇评测的价值在于，它用清晰的实测数据，帮助开发者在具体项目中根据业务核心需求——是极致的速度还是可靠的保障——来做出明智的引擎选择。

IT 累计浏览 4,733

恢复删除的数据表，数据库

这篇文章聚焦于一个常见但棘手的数据恢复场景：当管理员在执行恢复操作时，不慎误删了整个数据表或数据库，导致原有数据丢失。作者指出，即便在此刻紧急求助于专业的InnoDB数据恢复工具，往往也无力回天。根本原因在于，若此前配置了独立表空间（innodb-file-per-table），那么存放表结构与数据的整个目录都会被一并删除，使得恢复工具无从下手。同样的问题也发生在MyISAM引擎的表上。删除操作不仅会清空数据，还会连带删除所有关键的.MYD（数据文件）、.MYI（索引文件）以及.frm（表结构）文件，造成彻底的数据孤岛。这篇文章的价值在于，它通过具体的技术细节（如不同存储引擎的文件结构）清晰揭示了为何某些“删除”操作会带来不可逆的后果。对于所有需要进行数据库维护或恢复的工程师而言，这更像一个必须重视的警示：在执行任何涉及删除的高风险操作前，务必确认备份完备，并深入理解所使用存储引擎的数据存储机制。