前言

做网站开发或者运维的同学，肯定会遇到这种情况：需要给开发或者运营同学一个数据库账号，但是又不能给root权限，怕他们误操作删库。这时候就需要用到MySQL的用户和权限管理功能了。

很多新手同学只会用root账号登录数据库，不知道怎么创建新用户、怎么分配权限。这篇文章就把MySQL用户创建和权限管理的完整教程整理出来，从创建用户、授权、改密码到删除用户，一步一步讲清楚。

一、创建用户

首先我们来创建一个新用户。MySQL创建用户有两种方式：CREATE USER 和 GRANT。

方式1：用CREATE USER创建用户

CREATE USER 'testuser'@'localhost' IDENTIFIED BY '123456';

这个命令创建了一个叫testuser的用户，密码是123456，只能从本机（localhost）连接MySQL。

如果你想让用户可以从任何地方连接，可以把localhost改成%：

CREATE USER 'testuser'@'%' IDENTIFIED BY '123456';

注意：生产环境不建议用%，最好指定具体的IP地址，更安全。

方式2：用GRANT创建用户并直接授权

其实更常用的是创建用户的同时直接授权，一步到位：

GRANT ALL PRIVILEGES ON testdb.* TO 'testuser'@'localhost' IDENTIFIED BY '123456';

这个命令会自动创建testuser用户，并且把testdb数据库的所有权限都给它。

二、给用户授权

创建完用户之后，我们来给用户分配权限。MySQL的权限粒度很细，可以精确到某张表、某个字段。

常用权限说明

• ALL PRIVILEGES：所有权限
• SELECT：查询权限
• INSERT：插入权限
• UPDATE：更新权限
• DELETE：删除权限
• CREATE：创建表/数据库权限
• DROP：删除表/数据库权限
• ALTER：修改表结构权限
• INDEX：创建索引权限
• CREATE VIEW：创建视图权限
• PROCESS：查看进程权限
• RELOAD：执行flush权限
• SHOW DATABASES：查看所有数据库权限

给用户所有权限

GRANT ALL PRIVILEGES ON testdb.* TO 'testuser'@'localhost';

这个命令的意思是：把testdb数据库里所有表的所有权限都给testuser用户。

只给用户查询和修改权限

GRANT SELECT, INSERT, UPDATE, DELETE ON testdb.* TO 'testuser'@'localhost';

这样用户就只能查询、插入、修改、删除数据，不能修改表结构，也不能删表。

只给用户某张表的权限

GRANT SELECT ON testdb.users TO 'testuser'@'localhost';

这样用户只能查询testdb库里的users表，其他表都访问不了。

给用户所有数据库的权限

GRANT ALL PRIVILEGES ON *.* TO 'testuser'@'localhost';

.的意思是所有数据库的所有表。这个权限基本相当于root了，要谨慎使用。

授权之后一定要刷新权限

每次给用户授权之后，一定要执行下面这个命令刷新权限，不然授权可能不生效：

FLUSH PRIVILEGES;

三、查看用户权限

想知道某个用户有什么权限，可以用下面这个命令：

SHOW GRANTS FOR 'testuser'@'localhost';

执行完之后会显示这个用户的所有权限。

查看所有用户

如果想看看MySQL里有哪些用户，可以查询mysql.user表：

SELECT user, host FROM mysql.user;

四、修改用户密码

如果要修改某个用户的密码，可以用下面的命令：

ALTER USER 'testuser'@'localhost' IDENTIFIED BY '新密码';

修改完之后也要刷新权限：

FLUSH PRIVILEGES;

五、回收用户权限

如果用户权限给多了，想收回某些权限，可以用REVOKE命令：

收回所有权限

REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'testuser'@'localhost';

收回某个具体权限

REVOKE DELETE ON testdb.* FROM 'testuser'@'localhost';

这样用户就没有删除数据的权限了。

回收完权限之后也要刷新：

FLUSH PRIVILEGES;

六、删除用户

如果某个用户不需要了，可以删除：

DROP USER 'testuser'@'localhost';

注意：删除用户的时候，用户已有的权限也会一起被删掉。

七、创建用户的安全建议

1. 不要随便给用户ALL PRIVILEGES：按需授权，只给需要的权限就行
2. 不要用%允许所有IP连接：生产环境最好指定具体的IP
3. 不要用root账号给应用用：单独创建一个应用账号，只给需要的权限
4. 密码要复杂一点：不要用123456这种简单密码
5. 定期清理不用的用户：不用的用户及时删掉，减少安全隐患

常见坑

坑1：授权之后忘了FLUSH PRIVILEGES

很多同学授权完之后直接就用了，结果发现权限没生效。这就是因为忘了执行FLUSH PRIVILEGES。每次授权或者改密码之后，一定要执行一下这个命令刷新权限。

坑2：用户创建了但是连不上

很多同学创建完用户之后，用这个用户去连接数据库，结果连接失败。这一般是因为：

1. 你创建用户的时候指定的是localhost，但是你从其他IP连接
2. 防火墙没放行MySQL端口
3. 用户密码输错了

坑3：%和localhost搞混了

很多同学不知道'localhost'@'%'和'%'@'localhost'的区别。记住：用户名是前面的，后面的是允许连接的IP。

坑4：给了权限但是还是操作不了

有时候给了用户权限，但是用户还是操作不了。这一般是因为：

1. 忘了FLUSH PRIVILEGES
2. 表或者字段的权限没给
3. 用户根本就没有这个数据库的权限

总结

MySQL用户创建和权限管理的核心内容：

1. 创建用户：CREATE USER 或者 GRANT 直接创建并授权
2. 给用户授权：GRANT 权限 ON 数据库.表 TO 用户@IP
3. 查看权限：SHOW GRANTS FOR 用户
4. 改密码：ALTER USER 用户 IDENTIFIED BY 新密码
5. 回收权限：REVOKE 权限 ON 数据库.表 FROM 用户
6. 删除用户：DROP USER 用户
7. 所有操作完之后都要 FLUSH PRIVILEGES 刷新权限

记住这些命令，以后给应用或者同事分配数据库账号的时候就不用慌了。安全第一，不要随便给用户root权限。

遇到问题加QQ23979811 协助处理

前言

做运维的同学经常会遇到这种情况：服务器磁盘突然满了，不知道是哪个数据库或者哪张表占了这么多空间。或者想知道自己的数据库现在有多大了，好提前规划扩容。

这时候就需要用SQL命令来查看数据库和表的大小了。很多新手同学不知道怎么查，只能傻乎乎的用du命令看整个data目录的大小，看不到具体是哪个数据库或哪张表占了空间。

这篇文章就把MySQL查看数据库大小和表大小的常用SQL命令都整理出来，以后遇到磁盘满了的问题就能快速定位了。

一、查看所有数据库的大小

如果你想知道MySQL里每个数据库分别占了多少空间，可以执行下面这个SQL：

SELECT 
    table_schema AS '数据库名',
    ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS '大小(MB)'
FROM information_schema.tables
GROUP BY table_schema
ORDER BY SUM(data_length + index_length) DESC;

执行完之后会列出所有数据库的大小，单位是MB，从大到小排序。这样你一眼就能看出来哪个数据库最占空间了。

二、查看指定数据库的大小

如果你只想看某个数据库的大小，比如testdb数据库，可以执行：

SELECT 
    ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS '数据库大小(MB)'
FROM information_schema.tables
WHERE table_schema = 'testdb';

把testdb换成你要查询的数据库名就行。

三、查看数据库里所有表的大小

知道了哪个数据库大，接下来就要看这个数据库里哪张表最大了。执行下面这个SQL：

SELECT 
    table_name AS '表名',
    table_rows AS '行数',
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS '大小(MB)'
FROM information_schema.tables
WHERE table_schema = 'testdb'
ORDER BY (data_length + index_length) DESC;

这样就能列出testdb数据库里所有表的大小，从大到小排序。你一眼就能看出来哪张表最占空间了。

四、查看单张表的大小

如果你只想看某一张表的大小，比如users表，可以执行：

SELECT 
    table_name AS '表名',
    table_rows AS '行数',
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS '大小(MB)'
FROM information_schema.tables
WHERE table_schema = 'testdb' 
AND table_name = 'users';

五、查看表的详细大小（数据+索引分开）

有时候你想知道一张表里数据占了多少，索引占了多少，方便优化。可以执行：

SELECT 
    table_name AS '表名',
    ROUND(data_length / 1024 / 1024, 2) AS '数据大小(MB)',
    ROUND(index_length / 1024 / 1024, 2) AS '索引大小(MB)',
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS '总大小(MB)'
FROM information_schema.tables
WHERE table_schema = 'testdb'
ORDER BY (data_length + index_length) DESC;

六、查看数据库里所有表的行数

有时候你只想知道每张表有多少行数据，不需要看大小。可以执行：

SELECT 
    table_name AS '表名',
    table_rows AS '行数'
FROM information_schema.tables
WHERE table_schema = 'testdb'
ORDER BY table_rows DESC;

七、查看MySQL整体占了多少磁盘空间

如果你想知道整个MySQL一共占了多少磁盘空间，可以执行：

SELECT 
    ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS 'MySQL总大小(GB)'
FROM information_schema.tables;

常见坑

坑1：table_rows显示的行数不准确

很多同学发现，用 information_schema.tables 查出来的 table_rows 和实际 count(*) 出来的行数对不上。

这是因为 information_schema 里的 table_rows 是估算值，不是精确值。InnoDB引擎的话，这个值大概有10%左右的误差。如果需要精确的行数，还是得用 SELECT COUNT(*) FROM 表名。

坑2：查出来的大小和实际磁盘占用对不上

有时候你用SQL查出来的数据库大小，和用 du 命令查出来的 data 目录大小对不上，差了不少。

这是因为MySQL的data目录里除了表数据和索引，还有：

1. redo log、undo log这些日志文件
2. ibdata1这些系统表空间文件
3. 二进制日志文件

这些都不算在表数据和索引大小里。所以用SQL查出来的大小一般会比实际磁盘占用小一点。

坑3：查完之后发现有个库特别大，不知道是什么

有时候你查完发现有个库特别大，但是你根本不知道这个库是干嘛的。一般可能是：

1. mysql系统库
2. information_schema、performance_schema这些系统库
3. 之前测试的时候建的库，忘了删了

坑4：磁盘满了但是查出来数据库没多大

如果磁盘满了，但是查出来数据库没多大，那大概率不是数据库的问题，可能是：

1. 日志文件太大（比如nginx日志、MySQL的binlog日志）
2. 网站上传的文件太大
3. 系统临时文件太多

这时候需要去查一下具体是哪个目录占了空间。

总结

MySQL查看数据库和表大小的常用SQL命令总结一下：

1. 查看所有数据库大小：查 information_schema.tables，按 table_schema 分组
2. 查看指定数据库大小：加 WHERE table_schema = '数据库名'
3. 查看数据库里所有表的大小：按 table_name 分组
4. 查看单张表的大小：加 AND table_name = '表名'
5. 数据和索引分开看：data_length 和 index_length
6. 查看行数：table_rows 字段

记住这些SQL命令，以后遇到磁盘满了的问题，就能快速定位是哪个数据库、哪张表占了空间，不用再瞎找了。

遇到问题加QQ23979811 协助处理

前言

做运维或者开发的同学都知道，数据库是整个网站最核心的资产。一旦数据库出了问题，数据丢了，那损失可就大了。所以做好数据库备份是非常重要的一件事。

很多新手同学可能从来没做过数据库备份，等真的出问题了才后悔莫及。这篇文章就详细讲讲MySQL数据库怎么备份和恢复，包括常用的备份命令、恢复方法，还有自动定时备份的脚本。

一、备份方法

MySQL备份最常用的工具就是mysqldump，它是MySQL自带的备份工具，不需要额外安装。

1. 备份整个数据库

备份单个数据库是最常用的场景。比如你要把本地的testdb数据库备份成一个sql文件：

mysqldump -u root -p testdb > /root/testdb.sql

执行完之后输入MySQL的密码，就开始备份了。备份完之后会在/root/目录下生成一个testdb.sql文件。

2. 备份单张表

有时候你只需要备份数据库里的某一张表，比如只备份users表：

mysqldump -u root -p testdb users > /root/users.sql

3. 备份所有数据库

如果你想把MySQL里所有的数据库都备份下来，可以用 --all-databases 参数：

mysqldump -u root -p --all-databases > /root/all.sql

4. 只备份表结构，不备份数据

有时候你只需要备份表结构，不需要备份数据，这时候可以用 --no-data 参数：

mysqldump -u root -p --no-data testdb > /root/testdb_schema.sql

5. 备份的时候加锁保证数据一致性

备份大表的时候，为了保证备份过程中数据不被修改，可以加 --lock-tables 参数：

mysqldump -u root -p --lock-tables testdb > /root/testdb.sql

6. 备份的时候压缩文件

如果数据库很大，备份出来的sql文件也会很大，这时候可以用gzip压缩一下：

mysqldump -u root -p testdb | gzip > /root/testdb.sql.gz

二、恢复方法

备份完了，怎么恢复呢？

1. 恢复整个数据库

恢复整个数据库的命令：

mysql -u root -p testdb < /root/testdb.sql

注意：恢复之前一定要确保testdb这个数据库已经存在了。如果不存在，需要先创建数据库：

CREATE DATABASE testdb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

2. 恢复单张表

恢复单张表的话，先登录MySQL，然后选择对应的数据库，再用source命令恢复：

mysql -u root -p

USE testdb;
source /root/users.sql;

3. 恢复压缩的备份文件

如果你的备份文件是用gzip压缩过的，恢复的时候需要先解压：

gunzip < /root/testdb.sql.gz | mysql -u root -p testdb

三、自动定时备份脚本

手动备份太麻烦了，我们可以写个脚本，每天自动备份数据库。

备份脚本内容

创建一个备份脚本 /root/mysql_backup.sh：

#!/bin/bash

# 数据库配置
DB_USER="root"
DB_PASSWORD="你的MySQL密码"
DB_NAME="testdb"
BACKUP_DIR="/root/backup"

# 备份文件名，用日期命名
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/testdb_$DATE.sql"

# 创建备份目录
mkdir -p $BACKUP_DIR

# 执行备份
mysqldump -u$DB_USER -p$DB_PASSWORD $DB_NAME > $BACKUP_FILE

# 压缩备份文件
gzip $BACKUP_FILE

# 删除7天前的备份文件
find $BACKUP_DIR -name "*.sql.gz" -mtime +7 -delete

echo "备份完成：$BACKUP_FILE.gz"

给脚本加执行权限

chmod +x /root/mysql_backup.sh

添加到定时任务

用crontab添加定时任务，每天凌晨3点自动备份：

crontab -e

添加下面这行：

0 3 * * * /root/mysql_backup.sh

这样每天凌晨3点就会自动备份数据库了，而且只保留最近7天的备份，旧的会自动删除。

常见坑

坑1：备份的时候忘了加密码，执行的时候卡住了

很多同学写备份命令的时候，直接写 mysqldump -u root -p testdb > xxx.sql，然后执行的时候就会停下来让你输入密码。如果是在脚本里用的话，就会卡住。

解决方法是把密码直接写在命令里：mysqldump -u root -p你的密码 testdb > xxx.sql。注意-p和密码之间没有空格。

坑2：恢复的时候数据库不存在

很多同学恢复的时候直接执行 mysql -u root -p testdb < xxx.sql，结果报错说数据库不存在。记住恢复之前一定要先创建好对应的数据库。

坑3：备份文件太大，恢复的时候超时了

大文件恢复的时候很容易超时，或者因为各种原因中断。这时候可以用source命令在MySQL内部恢复，会稳定很多。

坑4：备份文件存在本地，服务器挂了备份也没了

很多同学备份文件直接放在服务器本地，觉得这样就安全了。其实不对，如果服务器磁盘坏了，或者被黑客删了，备份文件也没了。

正确的做法是：

1. 每天备份完之后，把备份文件下载到本地电脑
2. 或者上传到云存储（比如阿里云OSS、腾讯云COS）
3. 重要的备份最好异地多存几份

总结

MySQL数据库备份和恢复的核心内容：

1. 备份命令：mysqldump，常用参数有 --all-databases、--no-data、--lock-tables
2. 恢复命令：mysql < 备份文件，或者用source命令
3. 自动备份：写个shell脚本，配合crontab定时执行
4. 备份文件一定要异地存储，不能只放在服务器本地

数据库备份是个大事，千万不要等出问题了才想起来备份。养成每天自动备份的好习惯，出问题的时候才能从容应对。

遇到问题加QQ23979811 协助处理

前言

做网站开发的同学肯定遇到过这种情况：数据库里有一张几百万行甚至上千万行的大表，做分页查询的时候，第一页第二页查得很快，但是翻到第100页、第1000页的时候，查询就变得特别慢，甚至直接卡死。

这是为什么呢？怎么优化才能让大表分页查询不卡呢？这篇文章就详细讲讲MySQL大表分页越查越慢的原因，以及对应的优化方案。

为什么分页会越查越慢

先看一下最常见的分页查询写法：

SELECT * FROM orders ORDER BY id LIMIT 100000, 10;

这个SQL的意思是：从 orders 表里，跳过100000条数据，取后面10条。

很多同学以为这个查询很快就能出来，其实不是的。MySQL执行这个SQL的时候，会先扫描前100010条数据，然后把前面的100000条扔掉，只返回最后10条。

也就是说，你翻到第1000页的时候，MySQL要先扫描100000多条数据，然后再扔掉。翻的页数越深，MySQL要扫描和扔掉的数据就越多，所以查询就会越来越慢。

优化方案

方案1：子查询优化（延迟关联）

这是最常用的优化方案。思路就是：先用索引把需要的id查出来，然后再根据id去查完整的数据。

原来的慢查询：

SELECT * FROM orders ORDER BY id LIMIT 100000, 10;

优化后的写法：

SELECT o.* FROM orders o
INNER JOIN (
    SELECT id FROM orders ORDER BY id LIMIT 100000, 10
) t ON o.id = t.id;

这样优化的好处是：子查询里的 SELECT id FROM orders ORDER BY id LIMIT 100000, 10 只需要扫描索引就能完成，不需要回表查完整数据，速度会快很多。然后再根据查出来的10个id，去关联完整的表数据，只需要10次回表操作就行。

这种优化方式也叫"延迟关联"，是大表分页最常用的优化手段。

方案2：书签分页（记住上一页最后一条id）

如果你的业务场景允许（比如只允许"上一页"和"下一页"，不允许直接跳页），那用书签分页是最快的。

思路就是：记住上一页最后一条数据的id，下一页直接从这个id后面开始查。

第一页：

SELECT * FROM orders ORDER BY id LIMIT 10;

假设第一页最后一条数据的id是100。

第二页：

SELECT * FROM orders WHERE id > 100 ORDER BY id LIMIT 10;

这样不管你翻到第几页，查询速度都是一样快的，因为每次都是从某个id开始往后查10条，MySQL不需要扫描前面的几十万条数据。

这种分页方式的缺点是不支持直接跳页，只能一页一页往后翻。很多信息流产品（比如朋友圈、抖音）都是用这种分页方式。

方案3：覆盖索引

如果你查询的字段刚好都在索引里，那MySQL就不需要回表查完整数据了，速度会快很多。

比如你只需要查 id, title, create_time 这几个字段，那你可以建一个联合索引：

CREATE INDEX idx_title_time ON orders(title, create_time);

然后查询的时候只查这几个字段：

SELECT id, title, create_time FROM orders ORDER BY create_time LIMIT 100000, 10;

这样MySQL直接从索引里就能拿到所有需要的数据，不需要回表，查询速度会快很多。

方案4：禁止跳页查询

如果你的业务场景允许，可以考虑禁止用户直接跳页。比如只允许用户看前100页，或者只允许"上一页"和"下一页"。

因为翻到第1000页、第10000页的用户其实很少，大部分用户都是看前几页。禁止跳页可以避免大量深分页查询拖慢数据库。

常见坑

坑1：用LIMIT offset的时候，offset越大越慢

很多同学不知道LIMIT offset的原理，以为MySQL直接就跳过了前面的offset条数据。其实不是的，MySQL是先把前面的offset条数据都查出来，然后再扔掉。所以offset越大，查询越慢。

坑2：优化了子查询，但是子查询里没有用到索引

如果你的ORDER BY字段没有建索引，那就算用了子查询优化，还是会很慢。一定要确保ORDER BY的字段有索引。

坑3：书签分页的时候，id不是连续的

书签分页的前提是你的id是连续的、递增的。如果你的业务场景里id可能会被删除，导致id不连续，那书签分页可能会漏数据。这时候需要根据实际情况调整分页策略。

坑4：用count(*)查总页数很慢

大表查总页数也很慢，比如 SELECT COUNT(*) FROM orders，几百万行的表可能要查好几秒。

这个优化方案是：

1. 如果业务不需要精确的总页数，可以用"大约XX万条"来代替
2. 或者单独建一张表存总条数，定期更新
3. 或者用explain估算一下大概的行数

总结

MySQL大表分页越查越慢的问题，核心原因就是LIMIT offset会先扫描offset条数据然后扔掉，offset越大越慢。

常用的优化方案：

1. 子查询优化（延迟关联）：先查id，再关联完整数据
2. 书签分页：记住上一页最后一条id，下一页从这个id开始查
3. 覆盖索引：只查索引里有的字段，避免回表
4. 禁止跳页：不允许直接翻到第1000页

根据你的业务场景选择合适的优化方案，大表分页查询慢的问题就能很好地解决了。

遇到问题加QQ23979811 协助处理

MySQL 锁机制详解

MySQL 锁是并发控制的核心，搞懂锁，才能避免死锁和性能问题。

1. 表锁 vs 行锁

表锁：锁整个表，开销小，并发低。

• MyISAM 用的就是表锁
• 适合读多写少的场景

行锁：锁单行数据，开销大，并发高。

• InnoDB 用的就是行锁
• 适合写多的场景

2. 共享锁 vs 排他锁

共享锁（S锁）：读锁，多个读不互斥。

SELECT ... LOCK IN SHARE MODE

排他锁（X锁）：写锁，一个写独占。

SELECT ... FOR UPDATE

3. 间隙锁

InnoDB 用间隙锁防止幻读。锁的是一个范围，不是具体行。

比如你查 id > 10 AND id < 20，间隙锁会把这个区间锁住，别人插不进来。

4. 死锁

两个事务互相等对方的锁，都不放，就死锁了。

避免死锁的方法：

• 按相同顺序访问表
• 事务尽量小，快速提交
• 降低隔离级别
• 加索引，减少行锁范围

5. 查看锁状态

-- 查看当前锁
SHOW OPEN TABLES WHERE In_use > 0;

-- 查看 InnoDB 锁
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

-- 查看锁等待
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

6. 行锁什么时候会变成表锁

行锁失效就会升级成表锁：

• 没用索引
• 索引失效
• 全表扫描

所以加索引不仅是为了查得快，也是为了锁得准。

总结

MySQL 锁的核心：

• InnoDB 默认行锁，MyISAM 是表锁
• 共享锁读、排他锁写
• 间隙锁防幻读
• 死锁要避免：顺序访问、小事务、加索引

搞懂这些，数据库并发问题基本能解决一半。

MySQL 慢查询优化实战技巧

数据库慢查询是生产环境最常见的性能问题之一。掌握慢查询优化技巧，能让系统性能提升数倍。

1. 开启慢查询日志

先开启慢查询日志，找出哪些 SQL 慢：

slow_query_log = 1
long_query_time = 1
slow_query_log_file = /var/log/mysql/slow.log

超过1秒的查询就会被记录。

2. 用 Explain 分析

慢 SQL 拿到后，用 EXPLAIN 分析执行计划：

EXPLAIN SELECT * FROM users WHERE name = '张三';

重点看：

• type：访问类型，ALL 是全表扫描，要优化
• key：实际用到的索引
• rows：扫描行数
• Extra：额外信息，Using filesort、Using temporary 要警惕

3. 加索引

最直接的优化就是加索引：

ALTER TABLE users ADD INDEX idx_name(name);

加索引原则：

• WHERE、JOIN、ORDER BY 字段优先
• 区分度高的字段效果好
• 联合索引遵循最左前缀

4. 避免 SELECT *

只查需要的字段：

-- 不好
SELECT * FROM users WHERE id = 1;

-- 好
SELECT id, name FROM users WHERE id = 1;

5. 深分页优化

LIMIT 100000, 10 很慢，因为要扫描10万行：

-- 不好
SELECT * FROM users LIMIT 100000, 10;

-- 好，用子查询
SELECT * FROM users 
WHERE id >= (SELECT id FROM users LIMIT 100000, 1)
LIMIT 10;

6. 大表拆小

单表数据量超过千万行，性能会下降。可以：

• 按时间分表
• 按用户ID分库
• 归档历史数据

7. 总结

慢查询优化的核心思路：先找慢 SQL，再分析执行计划，然后加索引或改写 SQL。优化完记得对比前后效果，确保真的变快了。

MySQL 索引为什么能提速

索引是数据库性能优化的核心，搞懂原理才能用对。

1. 为什么慢查询慢

没有索引，MySQL 就得全表扫描，一行一行找。100万行数据就得扫100万次，当然慢。

有了索引，就像书有目录，直接定位到位置，查几百万行也很快。

2. B+ 树索引

MySQL InnoDB 默认用 B+ 树做索引。

• 树的高度低，一般3-4层
• 一次查询只需3-4次磁盘IO
• 叶子节点存数据，非叶子节点存索引

3. 聚簇索引 vs 二级索引

聚簇索引：数据和索引放在一起，按主键组织。一张表只有一个聚簇索引。

二级索引：索引和数据分开，叶子节点存主键值。查二级索引需要回表查主键。

4. 覆盖索引

如果查询的字段都在索引里，就不用回表了，叫覆盖索引。

-- name有索引
SELECT name FROM users WHERE name = '张三';
-- 覆盖索引，不用回表

5. 最左前缀

联合索引 (a, b, c)，必须从最左列开始用：

• WHERE a = 1 能用
• WHERE a = 1 AND b = 2 能用
• WHERE b = 2 用不了

6. 索引失效场景

• 索引字段做函数运算
• 隐式类型转换
• like 以 % 开头
• 联合索引不满足最左前缀

总结

索引是空间换时间。不是越多越好，太多索引会影响写入性能，占用额外存储空间。

MySQL 8.0 有哪些重要更新

MySQL 8.0 是目前最主流的大版本，相比 5.7 提升很大。

1. 性能提升

8.0 的性能比 5.7 提升约 2 倍，尤其是读取和写入并发场景下提升明显。

2. 原子 DDL

8.0 支持原子 DDL，建表、删表操作要么全成功要么全失败，不会出现一半成功一半失败的情况。

3. 窗口函数

支持窗口函数，比如 ROW_NUMBER()、RANK()，做排名统计很方便：

SELECT name, score,
  RANK() OVER (ORDER BY score DESC) as rank
FROM students;

4. CTE 公共表表达式

支持 WITH 语法，复杂 SQL 写起来更清晰：

WITH top_users AS (
  SELECT id, name FROM users WHERE vip = 1
)
SELECT * FROM top_users;

5. JSON 增强

JSON 操作函数更丰富，性能也更好，基本可以替代 MongoDB 的简单场景。

6. 隐藏索引

可以把索引设为隐藏状态，不删除但暂时不用，用来测试索引是否真的有用。

7. 字符集变化

默认字符集从 latin1 改成了 utf8mb4，支持 Emoji 表情。

总结

MySQL 8.0 是目前新项目的首选，性能好、特性全。老项目从 5.7 升级要注意兼容性，尤其是 SQL 模式和函数变化。

前言

数据库备份是生产环境的生命线。很多人没出事的时候不备份，出事了才后悔。本文讲清楚 MySQL 最常用的备份工具 mysqldump。

一、为什么要备份

• 误操作：手滑删了表、删了数据
• 服务器挂了：硬盘坏了、机器报废
• 被攻击： ransomware 加密了数据库
• 升级失败：新版本不兼容，数据回退

记住：没有备份的数据库，就是在裸奔。

二、mysqldump 是什么

mysqldump 是 MySQL 自带的逻辑备份工具，把数据导出成 SQL 文件。

优点：简单、通用、跨版本
缺点：大数据量慢

适合：中小数据库（< 50G）

三、备份数据库

1. 备份整个数据库

mysqldump -u root -p 数据库名 > backup.sql

输入密码后，就会生成 backup.sql 文件。

2. 备份所有数据库

mysqldump -u root -p --all-databases > all_backup.sql

3. 备份单个表

mysqldump -u root -p 数据库名 表名 > table_backup.sql

4. 备份多个表

mysqldump -u root -p 数据库名 表1 表2 > multi_backup.sql

四、恢复数据库

1. 恢复整个数据库

mysql -u root -p 数据库名 < backup.sql

注意：数据库要先存在。

CREATE DATABASE 数据库名;

2. 恢复所有数据库

mysql -u root -p < all_backup.sql

五、常用参数

--single-transaction

InnoDB 引擎下，保证备份一致性，不锁表：

mysqldump -u root -p --single-transaction 数据库名 > backup.sql

生产环境一定要加这个！

--routines

备份存储过程和函数：

mysqldump -u root -p --routines 数据库名 > backup.sql

--triggers

备份触发器：

mysqldump -u root -p --triggers 数据库名 > backup.sql

--events

备份事件调度器：

mysqldump -u root -p --events 数据库名 > backup.sql

--no-data

只备份表结构，不备份数据：

mysqldump -u root -p --no-data 数据库名 > schema.sql

--where

按条件备份：

mysqldump -u root -p 数据库名 表名 --where="id > 100" > partial.sql

六、完整备份命令

生产环境推荐用这个：

mysqldump -u root -p \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --default-character-set=utf8mb4 \
  数据库名 > backup.sql

七、压缩备份

备份文件太大？压缩一下：

# 备份并压缩
mysqldump -u root -p 数据库名 | gzip > backup.sql.gz

# 解压并恢复
gunzip < backup.sql.gz | mysql -u root -p 数据库名

八、定时备份

写个脚本每天自动备份：

#!/bin/bash

# 备份目录
BACKUP_DIR="/data/backup/mysql"
DATE=$(date +%Y%m%d)

# 备份
mysqldump -u root -p密码 --single-transaction 数据库名 | gzip > $BACKUP_DIR/db_$DATE.sql.gz

# 删除 7 天前的备份
find $BACKUP_DIR -name "db_*.sql.gz" -mtime +7 -delete

加到 crontab：

# 每天凌晨 2 点备份
0 2 * * * /bin/bash /path/to/backup.sh

九、常见坑

1. 备份不锁表：大表备份会锁表，一定要加 --single-transaction
2. 字符集不对：备份文件乱码，加 --default-character-set=utf8mb4
3. 没备份存储过程：导出后丢了，加 --routines
4. 备份没验证：备份完一定要试恢复，不然真出事的时候哭都来不及

十、备份策略

• 每天全量备份：小数据库
• 每周全量 + 每天增量：大数据库
• 异地备份：备份文件要存到别的服务器
• 定期演练恢复：每个月测一次能不能恢复

总结

MySQL 备份的核心要点：

1. mysqldump 是最常用的备份工具
2. 生产环境加 --single-transaction，不锁表
3. 备份要压缩，节省空间
4. 定时备份，自动删除旧备份
5. 备份一定要验证，能恢复才算备份成功

数据是公司最值钱的资产，备份这事儿千万别偷懒。

前言

事务和锁是 MySQL 最核心也最容易出问题的部分。很多人写了很多年 SQL，却还是搞不清隔离级别和死锁。本文用最直白的方式讲清楚。

一、事务的 ACID

事务就是一组操作，要么全部成功，要么全部失败。四个特性：

• A 原子性：一组操作是一个整体，不能拆分
• C 一致性：事务前后，数据库从一个一致状态到另一个一致状态
• I 隔离性：多个事务之间互不干扰
• D 持久性：事务提交后，数据就永久保存了

二、并发问题

多个事务同时操作数据，会出什么问题？

1. 脏读

事务 A 读到了事务 B 还没提交的数据。

事务 A：修改了余额为 1000，但还没提交
事务 B：读到了余额 1000
事务 A：回滚了，余额变回 500
事务 B：拿着 1000 的错误数据继续操作

2. 不可重复读

事务 A 两次读同一行数据，结果不一样。

事务 A：第一次读余额是 500
事务 B：修改了余额为 1000，提交了
事务 A：第二次读余额是 1000

3. 幻读

事务 A 两次查询，结果集的行数不一样。

事务 A：第一次查询 age > 20 的用户，有 10 条
事务 B：插入了一条 age = 25 的用户，提交了
事务 A：第二次查询 age > 20 的用户，有 11 条

三、四种隔离级别

MySQL 用隔离级别来解决这些并发问题：

MySQL 默认是可重复读（REPEATABLE READ），InnoDB 在这个级别下用间隙锁解决了幻读。

查看当前隔离级别

SELECT @@tx_isolation;

修改隔离级别

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

四、锁的类型

1. 共享锁（S 锁）

读锁，多个事务可以同时持有。

SELECT ... LOCK IN SHARE MODE;

2. 排他锁（X 锁）

写锁，只有一个事务能持有。

SELECT ... FOR UPDATE;

3. 表锁 vs 行锁

• 表锁：锁住整张表，开销小，但并发低
• 行锁：锁住一行数据，开销大，但并发高

五、死锁

什么是死锁

两个事务互相等待对方释放锁。

事务 A：锁住了 id = 1，等待 id = 2
事务 B：锁住了 id = 2，等待 id = 1

两个事务都卡住了，谁也不让谁。

怎么避免死锁

1. 按相同顺序访问表和行：所有事务都按 id 从小到大操作
2. 事务尽量短：事务越长，锁持有时间越长
3. 降低隔离级别：隔离级别越低，锁越少
4. 加索引：没有索引会走表锁，更容易死锁

查看死锁

-- 查看最近一次死锁
SHOW ENGINE INNODB STATUS;

六、实战：转账

-- 开启事务
BEGIN;

-- 扣款（加行锁）
UPDATE account SET balance = balance - 100 WHERE id = 1;

-- 检查余额
SELECT balance FROM account WHERE id = 1;

-- 如果余额不够，回滚
-- ROLLBACK;

-- 加钱
UPDATE account SET balance = balance + 100 WHERE id = 2;

-- 提交
COMMIT;

七、常见坑

1. 事务太长：锁持有时间太长，容易死锁
2. 没有索引：行锁变表锁，并发暴跌
3. 隔离级别太高：用串行化，性能很差
4. 忘记提交：事务一直开着，锁一直占着

总结

MySQL 事务与锁的核心思路：

1. 事务保证 ACID，一组操作要么全成功要么全失败
2. 隔离级别越高越安全，但性能越差
3. MySQL 默认可重复读，InnoDB 解决了幻读
4. 行锁比表锁并发高，但一定要有索引
5. 按相同顺序操作，能避免大部分死锁

搞懂这些，你对 MySQL 的理解就超过 80% 的开发者了。

前言

数据库查询慢是 Web 开发中最常见的性能问题之一。而绝大多数慢查询都可以通过合理使用索引来解决。本文将从 Explain 执行计划入手，带你一步步掌握 MySQL 索引优化的实战技巧。

一、认识 Explain 执行计划

要优化查询，首先得知道 MySQL 是怎么执行你的 SQL 的。EXPLAIN 命令可以展示 MySQL 执行查询的详细步骤：

EXPLAIN SELECT * FROM orders WHERE user_id = 10086 AND status = 'paid';

重点关注以下几个字段：

• type：访问类型，从好到差依次为 const > eq_ref > ref > range > index > ALL。出现 ALL 就是全表扫描，必须优化。
• key：实际使用的索引。如果为 NULL，说明没有用到索引。
• rows：预估需要扫描的行数。这个值越大越慢。
• Extra：额外信息。Using filesort 和 Using temporary 都是危险信号。

二、最左前缀原则

联合索引 (a, b, c) 的匹配规则：

-- 用到索引 a,b,c
SELECT * FROM t WHERE a = 1 AND b = 2 AND c = 3;

-- 用到索引 a,b
SELECT * FROM t WHERE a = 1 AND b = 2;

-- 只用到索引 a（中间断了）
SELECT * FROM t WHERE a = 1 AND c = 3;

-- 完全用不到索引
SELECT * FROM t WHERE b = 2 AND c = 3;

实战要点：把等值查询的列放在前面，范围查询的列放在后面。

三、常见索引失效场景

1. 对索引列使用函数或运算

-- 失效：对索引列用了函数
SELECT * FROM users WHERE DATE(created_at) = '2026-01-01';

-- 有效：改成范围查询
SELECT * FROM users WHERE created_at >= '2026-01-01' AND created_at < '2026-01-02';

2. 隐式类型转换

-- 失效：phone 是 varchar，用数字查
SELECT * FROM users WHERE phone = 13800138000;

-- 有效：加引号
SELECT * FROM users WHERE phone = '13800138000';

3. LIKE 以通配符开头

-- 失效
SELECT * FROM users WHERE name LIKE '%张%';

-- 有效
SELECT * FROM users WHERE name LIKE '张%';

四、实战优化案例

问题 SQL（扫描 10 万行，耗时 1.2 秒）：

SELECT id, title, created_at FROM articles
WHERE category_id = 5 AND status = 'published'
ORDER BY created_at DESC LIMIT 20;

Explain 结果：type=index，rows=120000，Using filesort。

优化方案：创建联合索引

ALTER TABLE articles ADD INDEX idx_cat_status_time (category_id, status, created_at DESC);

优化后：type=ref，rows=20，Extra 无 filesort。查询时间从 1.2 秒降到 0.005 秒。

五、索引不是越多越好

索引虽然能加速查询，但也有代价：

1. 写入变慢：每次 INSERT/UPDATE 都要维护索引
2. 占用空间：索引也是要存磁盘的
3. 优化器选错：索引太多可能让优化器犯迷糊

建议：单表索引数量控制在 5 个以内，避免重复索引和冗余索引。

总结

MySQL 索引优化的核心思路：

1. 用 EXPLAIN 看执行计划，找到慢的原因
2. 遵循最左前缀原则设计联合索引
3. 避免常见的索引失效写法
4. 定期清理无用索引

掌握这些技巧，你就能解决 80% 以上的慢查询问题。

MySQL两表关联更新操作无效的解决办法对于描述的问题，即在满足特定条件时，根据一张表中的字段值更新另一�...

理解MySQL更新的底层机制，助力大批量数据更新在应用程序中，我们经常需要更新数据库中的大量数据。在...

查询特定的字段值问题：如何查询MySQL数据库中某个表中特定的字段值？解决方案：可以使用以下SQL...

解决MySQL中MyISAM与InnoDB行锁争抢的问题在使用MySQL...

MySQLSQL求解特定分组问题：如何使用GROUPBY...

MySQLupdate语句中left...

解析Mysql中复杂数据结构对于存放在数据库中的复杂数据结构，如在问题中给出的序列化字符串，我们需要将其�...

如何分解MySQL中存储的序列化PHP数组在MySQL数据库中，数据经常以序列化PHP...