MySQL 数据库优化与备份恢复实战指南

数据库优化是每个开发者都要面对的课题,今天咱们就像师徒聊天一样,把 MySQL 优化和备份恢复这件事说透。

先说查询优化。很多新手写 SQL 只关心能不能查出结果,却不关心查得快不快。你打开慢查询日志,会发现大部分性能问题都出在没有索引上。比如你有个用户表,经常按手机号查询,那就得给手机号字段加索引。创建索引很简单,执行 CREATE INDEX idx_phone ON users(phone) 就行。但索引不是越多越好,每个索引都会占用存储空间,还会拖慢写入速度。记住一个原则:给查询条件中最常使用的列加索引,给区分度高的列加索引。

说到查询语句本身,能用 SELECT 具体字段就别用 SELECT *。假设你只需要用户 ID 和姓名,就写 SELECT id, name FROM users。这样不仅减少网络传输,还能让 MySQL 利用覆盖索引,直接从索引树里取数据,不用回表查询。另外,避免在 WHERE 子句里对字段做函数运算,比如 WHERE DATE(create_time) = ‘2026-03-21’ 会让索引失效,改成 WHERE create_time >= ‘2026-03-21 00:00:00’ AND create_time backup.sql 就能导出整个数据库。但生产环境数据量大,建议加上 single-transaction 参数避免锁表,写成 mysqldump -u root -p –single-transaction database_name > backup.sql。如果要备份所有数据库,用 –all-databases 参数。

恢复数据更简单,执行 mysql -u root -p database_name < backup.sql 就能把备份文件导入回去。但恢复前一定要确认目标数据库存在,不存在的话先 CREATE DATABASE database_name。

自动备份很重要,写个 shell 脚本放在 crontab 里每天凌晨执行。脚本里加上日期后缀,比如 backup_$(date +%Y%m%d).sql,这样能保留多天的备份。记得把备份文件传到远程服务器或云存储,防止服务器挂了备份也跟着丢。

最后说说主从复制。配置主从不仅能做读写分离,还能当热备份用。主库开启 binlog,从库同步主库的 binlog 日志,这样从库数据几乎实时和主库一致。万一主库出问题,能快速切换到从库。

数据库优化没有银弹,得根据实际业务场景分析。养成看执行计划的习惯,用 EXPLAIN 命令看看 SQL 是怎么执行的,有没有用到索引,有没有全表扫描。多实践多观察,你自然就知道怎么优化了。

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇