Share E-Book
Scan to open this page

Scan with your phone to open this page

AuthorJeremy Tinley(杰里米·廷利) (美)Silvia Botros(西尔维亚·博特罗斯)

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
Publish Year: 2022
Language: Chinese
File Format: PDF
File Size: 5.7 MB
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…