mysql-Optimization Overview-数据库调优

Database performance depends on several factors at the database level, such as tables, queries, andconfiguration settings. These software constructs result in CPU and I/O operations at the hardware level,which you must minimize and make as efficient as possible. As you work on database performance, youstart by learning the high-level rules and guidelines for the software side, and measuring performanceusing wall-clock time. As you become an expert, you learn more about what happens internally, and start measuring things such as CPU cycles and I/O operations.

Typical users aim to get the best database performance out of their existing software and hardware

configurations. Advanced users look for opportunities to improve the MySQL software itself, or develop

their own storage engines and hardware appliances to expand the MySQL ecosystem.

• Optimizing at the Database Level

• Optimizing at the Hardware Level

• Balancing Portability and Performance

Optimizing at the Database Level

The most important factor in making a database application fast is its basic design:

• Are the tables structured properly? In particular, do the columns have the right data types, and does

each table have the appropriate columns for the type of work? For example, applications that perform

frequent updates often have many tables with few columns, while applications that analyze large

amounts of data often have few tables with many columns.

• Are the right indexes in place to make queries efficient?

• Are you using the appropriate storage engine for each table, and taking advantage of the strengths and

features of each storage engine you use? In particular, the choice of a transactional storage engine

such as InnoDB or a nontransactional one such as MyISAM can be very important for performance and

scalability.

Note

InnoDB is the default storage engine for new tables. In practice, the advanced

InnoDB performance features mean that InnoDB tables often outperform the

simpler MyISAM tables, especially for a busy database.

• Does each table use an appropriate row format? This choice also depends on the storage engine used

for the table. In particular, compressed tables use less disk space and so require less disk I/O to read

and write the data. Compression is available for all kinds of workloads with InnoDB tables, and for read

only MyISAM tables.

• Does the application use an appropriate locking strategy? For example, by allowing shared access

when possible so that database operations can run concurrently, and requesting exclusive access when

appropriate so that critical operations get top priority. Again, the choice of storage engine is significant.

The InnoDB storage engine handles most locking issues without involvement from you, allowing for

better concurrency in the database and reducing the amount of experimentation and tuning for your

code.

• Are all memory areas used for caching sized correctly? That is, large enough to hold frequently

accessed data, but not so large that they overload physical memory and cause paging. The main

memory areas to configure are the InnoDB buffer pool, the MyISAM key cache, and the MySQL query

cache.

Optimizing at the Hardware Level

Any database application eventually hits hardware limits as the database becomes more and more busy.

A DBA must evaluate whether it is possible to tune the application or reconfigure the server to avoid these

1319Balancing Portability and Performance

bottlenecks, or whether more hardware resources are required. System bottlenecks typically arise from

these sources:

• Disk seeks. It takes time for the disk to find a piece of data. With modern disks, the mean time for this

is usually lower than 10ms, so we can in theory do about 100 seeks a second. This time improves

slowly with new disks and is very hard to optimize for a single table. The way to optimize seek time is to

distribute the data onto more than one disk.

• Disk reading and writing. When the disk is at the correct position, we need to read or write the data. With

modern disks, one disk delivers at least 10--20MB/s throughput. This is easier to optimize than seeks

because you can read in parallel from multiple disks.

• CPU cycles. When the data is in main memory, we must process it to get our result. Having large tables

compared to the amount of memory is the most common limiting factor. But with small tables, speed is

usually not the problem.

• Memory bandwidth. When the CPU needs more data than can fit in the CPU cache, main memory

bandwidth becomes a bottleneck. This is an uncommon bottleneck for most systems, but one to be

aware of.

Balancing Portability and Performance

To use performance-oriented SQL extensions in a portable MySQL program, you can wrap MySQL

specific keywords in a statement within /*! */ comment delimiters. Other SQL servers ignore the

commented keywords. For information about writing comments, see Section 9.6, "Comment Syntax".

相关推荐
a栋栋栋18 小时前
wsl 环境下用Docker 安装多版本MySQL
mysql·docker·容器
Jayyih18 小时前
嵌入式系统学习Day35(sqlite3数据库)
数据库·学习·sqlite
得意霄尽欢21 小时前
Redis之底层数据结构
数据结构·数据库·redis
hsjkdhs21 小时前
MySQL 数据类型与运算符详解
数据库·mysql
爱吃烤鸡翅的酸菜鱼1 天前
【Redis】常用数据结构之Hash篇:从常用命令到使用场景详解
数据结构·数据库·redis·后端·缓存·哈希算法
李少兄1 天前
IntelliJ IDEA 启动项目时配置端口指南
数据库·sql·intellij-idea
NineData1 天前
NineData云原生智能数据管理平台新功能发布|2025年8月版
数据库·mongodb·云原生·数据库管理工具·ninedata·数据库迁移·数据复制
白云如幻1 天前
【Java】QBC检索和本地SQL检索
java·数据库·sql
勘察加熊人1 天前
python将pdf转txt,并切割ai
数据库·python·pdf
不良人天码星1 天前
Redis单线程模型为什么快?
数据库·redis·缓存