mysql的使用方法

MySQL 装好之后，使用第一件让人卡住的使用事往往不是写 SQL，而是使用连不上。我在本地用 root 登录，使用敲下 mysql -u root -p，使用输完密码却报“Access denied”。使用折腾半天才发现，使用MySQL 8 默认的使用认证插件是 caching_sha2_password，一些老客户端根本不认。使用解决办法也简单，使用登进去执行 ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的使用新密码';，再 FLUSH PRIVILEGES;。使用这坑我踩过两次，使用第二次是使用帮同事调环境，他用的使用 Navicat 版本太旧，同样卡在这里。

连上之后，建库建表是最常干的事。我习惯先 CREATE DATABASE shop DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci;，字符集别用 utf8，那是个历史遗留的坑，存 emoji 会直接报错。建表时主键用 INT UNSIGNED AUTO_INCREMENT 还是 BIGINT，得看业务量。我做过一个订单表，一开始用 INT，跑到两千万行时开始担心溢出，后来改成 BIGINT 才踏实。字段类型也有讲究，比如金额别用 FLOAT，用 DECIMAL(10,2)，否则对账时会出现 0.1+0.2 不等于 0.3 的经典问题。

增删改查里，SELECT 的花样最多。 WHERE 后面跟条件时，索引能不能用上，直接决定查询是毫秒还是秒级。有次我写了个 WHERE DATE(create_time) = '2024-01-01'，表里三百万行，跑了八秒多。后来改成 WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'，瞬间降到几十毫秒。函数包在字段上，索引就废了，这个规则我拿小本本记过。 JOIN 也类似，小表驱动大表，别反着来。 EXPLAIN 是个好东西，看 type 列是不是 ALL，key 列是不是 NULL，基本能判断问题在哪。

索引不是越多越好。我见过一个表建了十几个索引，写入慢得像蜗牛。每插一行，所有索引都要更新。通常来说，WHERE、ORDER BY、GROUP BY 用到的字段建索引，联合索引注意最左前缀。比如 INDEX(a, b, c)，查询条件只有 b 和 c 就用不上。另外，区分度低的字段，比如性别，单独建索引没意义，全表扫描可能更快。

事务这块，InnoDB 默认是 REPEATABLE READ。我做过一个转账场景，两个会话同时更新同一行，没加 FOR UPDATE 的话，后提交的会覆盖前一个。后来用 SELECT ... FOR UPDATE 锁住行，再更新，才保证一致性。但锁用多了容易死锁，两个事务互相等对方的锁，MySQL 会检测到并回滚其中一个，报 Deadlock found。遇到这种情况，要么调整业务逻辑顺序，要么缩短事务持有锁的时间。

备份和恢复，我一般用 mysqldump -u root -p shop > shop.sql，恢复就 mysql -u root -p shop < shop.sql。数据量大的话，这招很慢，可以考虑 SELECT ... INTO OUTFILE 或者物理备份工具。有一次我误删了一张表，幸好前一天做了 dump，只丢了半天数据。从那以后，定时任务里加了一条每天凌晨三点的备份命令。

MySQL 的坑不少，但摸清楚脾气之后，它还是挺顺手的。别指望一次写对，多试、多看执行计划、多查慢日志，慢慢就有感觉了。

很赞哦!（39713）