No description
AI Reading Assistant
Whole-book reading guide from stratified index samples; jump to passages in the text
AI guide
# High Performance MySQL (4th Edition) — Reading Guide
## 【One-Line Pitch】
The definitive practical handbook for running MySQL at scale — covering everything from storage engine internals and indexing strategy to hardware tuning, schema migrations, and SRE-style monitoring — essential reading for DBAs, backend engineers, and architects who operate MySQL in production.
## 【Book Arc】
- **Opening (~0%–11%)**: Foundations of MySQL architecture — locking mechanisms, transaction semantics, InnoDB as the default engine, and the shift toward defining service-level objectives (SLI/SLO/SLA) as the starting point for performance work.
- **Early (~11%–28%)**: Monitoring and hardware — using Performance Schema for query and memory inspection, then moving to operating system and hardware optimization including RAID levels, network configuration, and OS-level diagnostics with vmstat/iostat.
- **Middle (~28%–44%)**: InnoDB deep dive and schema management — buffer pool tuning, purge/undo log management, advanced InnoDB settings, data type selection (CHAR vs. VARCHAR, BIT, SET), and the critical practice of running online schema changes in production.
- **Middle (~44%–61%)**: Indexing strategy — index types, prefix indexes and selectivity, the importance of column order in composite indexes, and why ORM users still must understand indexes.
- **Late (~61%–end)**: Query optimization — understanding the full query lifecycle, reading execution plans, avoiding unnecessary scans, optimizing joins, and the eternal trade-off between "fast, accurate, and simple."
## 【Key Takeaways】
- **Locking is a balance between overhead and safety** (Early): MySQL offers multiple storage engines with different lock granularities; InnoDB's row-level locking with MVCC is the default choice for good reason, but lock management itself consumes resources that must be accounted for in high-concurrency designs.
- **SLOs come before performance tuning** (Early): Define SLIs (what to measure), SLOs (acceptable ranges), and SLAs before optimizing anything — this turns performance work from a technical exercise into a business-aligned practice and guides prioritization across teams.
- **Performance Schema is your window into server internals** (Early): Enable specific instruments to inspect SQL statements, memory usage, and locks; the `threads` table is the key to correlating processlist IDs with internal THREAD_IDs when diagnosing blocking issues.
- **Hardware and OS choices set your performance ceiling** (Early): RAID 0 is never acceptable for production (failure probability exceeds single disks), RAID 5 becomes viable with SSDs, and simple network issues like 1% packet loss or slow DNS resolution can devastate MySQL performance — enable `skip_name_resolve` on production servers.
- **InnoDB tuning requires understanding its internals** (Middle): The buffer pool, purge threads, and I/O capacity settings (`innodb_io_capacity`, `innodb_buffer_pool_instances`) directly impact scalability; a growing undo log with a long history list signals purge lag that must be addressed before it fills the disk.
- **Schema changes in production need online tools** (Middle): Even with MySQL 8.0's expanded INPLACE/INSTANT DDL support, large tables may still require external tools like `pt-online-schema-change` or `gh-ost` for throttled, non-blocking migrations — and CI integration should enforce schema-change discipline.
- **Index selectivity drives query performance** (Middle): Prefix indexes save space but reduce selectivity; measure cardinality to find the right prefix length, and remember that composite index column order matters because MySQL only uses the leftmost prefix effectively.
- **Query optimization starts with understanding the lifecycle** (Late): Most slow queries involve unnecessary operations, repeated work, or overly slow steps; use `SHOW FULL PROCESSLIST` states to identify bottlenecks, and remember that `COUNT()` queries are inherently hard to optimize — you must choose between fast, accurate, and simple.
## 【Reading Tips】
- **Skim the opening chapters on locking and transactions** if you already know ACID basics — the key insight is that InnoDB is the default for good reason, and MVCC with gap locks prevents phantom reads at REPEATABLE READ.
- **Deep-read the Performance Schema chapter** (Early) — it's dense but pays off immediately; focus on the `events_statements_history` tables and the `threads` table, which are the most practically useful for daily diagnosis.
- **The hardware chapter (Early) is skimmable for cloud users** but don't skip the network section — DNS resolution and port range issues are common even in managed environments.
- **Pay special attention to the InnoDB tuning section (Middle)** — the discussion of purge lag and `innodb_max_purge_lag` is rare practical wisdom you won't find in official docs; the schema-change tooling comparison is also worth careful reading.
- **The indexing and query optimization chapters (Middle–Late) deserve multiple passes** — the examples build on each other, and the discussion of why ORMs can't save you from understanding indexes is essential for application developers.
## 【Coverage Limits】
This guide synthesizes the first ~61% of the book (through query optimization fundamentals). The excerpts do not cover the later chapters on replication, backup/recovery, disaster recovery, or regulatory compliance — these are referenced but not detailed in the available material.
##
Excerpt 1
源上同时进行更改操作,只 要被修改的数据彼此不冲突即可。 问题是加锁也需要消耗资源。锁的各种操作,包括获取锁、检查锁是 否空闲、释放锁等,都会增加系统的开销。如果系统花费大量的时间 来管理锁,而不是存取数据,那么系统的性能可能会受影响。 锁定策略是锁开销和数据安全性之间的平衡,这种平衡会影响性能。 大多数商业数据...
View in text
Excerpt 2
用performance schema Performance Schema将内存使用统计信息存储在摘要表中,摘要表的 名称以memory_summary_前缀开头。内存使用聚合统计,其参数如表3- 8所示。 表3-8:内存使用的聚合参数 例如,要找到占用大部分内存的InnoDB结构,可以执行以下查询: VARI...
View in text
Excerpt 3
ted通常保持在100到120之间,那么可以将缓 存大小设置为20。如果停留在500到700之间,那么将缓存大小设置为 200也足够大了。可以这样想:当同时有700个连接时,缓存中线程全 部用光,当只有500个连接时,将有200个缓存线程作为备用,即便工 作负载随后再增加到700也够用了。 对于大多数使用场景来说...
View in text
Excerpt 4
tomer_id放到前面,因为对应 条件值的customer_id数量更小。我们再来看看对于这个customer_id 的条件值,对应的staff_id列的选择性如何: 这样做有一个地方需要注意,查询的结果非常依赖于选定的具体值。 如果按上述办法优化,可能对其他一些条件值的查询不公平,服务器 的整体性能可能会变得...
View in text
Excerpt 5
递到另一列上。例如,我们看下面的查询: 因为这里使用了film_id字段进行等值联接,MySQL知道这里的WHERE子 句不仅适用于film表,而且对于film_actor表同样适用。如果使用的 是其他的数据库管理系统,可能还需要手动通过一些条件来告知优化 器这个WHERE条件适用于两个表,那么写法就会如下: 在...
View in text
Excerpt 6
与源库完全一样的拷贝,但以我们的经验,源库与副本数据不 匹配是很常见的,并且MySQL没有方法检测这个问题。检测这个问 题的唯一方法是使用Percona Toolkit中的pt-table-checksum之 类的工具。防止这种情况的最好方法是使用super_read_only来确 保只有复制可以写入副本。 拥有...
View in text
Excerpt 7
性 ProxySQL还有很多其他功能,使其在通用应用程序代理中脱颖而出: ● 基于端口、用户或简单正则匹配的查询路由。 ● 在前端应用程序连接和后端到数据库的连接上都支持TLS。 ● 支持各种MySQL风格,如AWS Aurora、Galera Cluster和 Clickhouse。 ● 连接镜像。 ● 缓存结...
View in text
Excerpt 8
read_only标志可以作为一个很好的选择。如果服务器是 可写的,很可能不应该升级它,因为它可能正在进行生产写操 作。你还可以在这个步骤验证尚未升级的服务器。这样可以多次 运行升级脚本而不会重复升级同一台服务器。 2. 设置停机时间。 如果你的系统配置了监控告警,下一步涉及设置某种形式的停机 时间或警报抑制,避...
View in text
Tags
AI categories
DatabaseBackendProgramming Language
Text Preview (First 20 pages)
Registered users can read the full content for free
Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.
Generating text preview…
Loading comments...
Reply to Comment
Edit Comment