先说明一下这篇基础二和“基础一”的定位不一样。“基础一”把安装、建库、建表、基本增删改查讲完了你手里已经有了一把能跑起来的刀。但真正开始做项目、刷面试题、接手线上库的时候你会发现光会select * from users这种操作远远不够——条件过滤怎么写才不漏数据多张表的数据怎么关联一条update怎么避免把整表数据带沟里并发一上来事务和锁又是什么这篇MySQL基础二就是从“会写SQL”往“写好SQL”过渡的实操笔记覆盖进阶查询、多表join、事务与锁、存储过程与触发器、索引与explain还有几个高频报错的排查路子。适合刚学完基础语法、准备上手项目或正在准备面试的读者也欢迎偶尔回来翻翻速查。1. 查询进阶过滤、排序、分页里的坑与套路很多人写select是从“全表捞数据”开始的等数据量上来、条件变复杂才发现自己连where都没写明白。这一节我把日常最常用、也最容易被坑的查询细节拆开讲每一条都是真实踩过坑之后总结的。1.1 条件过滤NULL、隐式转换和日期边界先说NULL。新手最容易犯的错就是拿去查NULL。比如想看“没有填写手机号的用户”写where phone null结果一条都查不出来。原因很简单null不是一个值它表示“不确定”所以和任何值比较结果都是“不确定”不会返回True。要查NULL只能用is null反向就是is not null。更隐蔽的是“不等于”的场景。你想排除某个值比如where name admin如果字段里存在null这些行会被一并排除掉。因为null admin的结果也不是True。很多人统计时莫名少了几行数据就是栽在这里。正确习惯是如果字段允许为空并且“不等于”确实是业务想要的就写成(name admin or name is null)。再有一个高频坑是隐式类型转换。手机号、订单号这类字段如果建表时用了varchar查询时写成where phone 13800138000数字MySQL会尝试把phone字段转成数字再比较。这会导致字段上的索引失效更麻烦的是where phone 13800138000和where phone 13800138000在某些场景下结果都不一样比如有前导零的数据。这个没什么好讨论的凡是字符串字段条件里就老老实实加引号。日期边界问题也值得单独说。经常有人写where create_time between 2025-01-01 and 2025-01-31如果create_time是datetime类型这条SQL会漏掉2025-01-31 00:00:00之后的数据。因为between是两个边界都包含但2025-01-31会被转成2025-01-31 00:00:00当天白天产生的数据全被漏了。我自己的习惯是日期查询一律用左闭右开区间where create_time 2025-01-01 and create_time 2025-02-01。这样既不会漏也能让优化器更舒服地走索引。还有一个细节模糊匹配里%和_都是通配符%表示任意多个字符_表示任意一个字符。如果业务上真的要在条件里匹配%或_这个字符本身需要用escape指定转义符比如where remark like %50!%% escape !表示匹配包含“50%”的字符串。平时不常见但遇到一次够你折腾半天。1.2 排序不只是order by那么简单排序的语法确实简单order by后面跟字段就行但实际使用时有几个点值得注意。多字段排序时每个字段都可以单独指定asc升序或desc降序比如order by category_id asc, create_time desc。含义是先按分类升序排同一个分类里再按创建时间降序排。这个不难但很多人会写成order by category_id, create_time desc默认前面字段是升序倒也没错只是容易看迷糊建议养成显式写asc/desc的习惯。中文排序是个隐藏的坑。MySQL默认排序规则是按字符集的编码顺序排的如果字段用的是utf8mb4_unicode_ci中文排序结果通常是按Unicode编码来和拼音顺序不一定一致。如果你确实需要按拼音排可以把排序规则临时指定成gbk_chinese_ci在order by后面用collate或者就接受这种排序结果。记住排序不是按“你脑子里的习惯”排的而是按“字符集排序规则”排的搞清楚这个逻辑很多疑惑就迎刃而解了。另外如果你看到执行计划里出现Using filesort说明排序并没有用到索引MySQL需要额外做一次排序操作。数据量小的时候无所谓数据量大就会拖慢查询。这个知识点先记着后面讲索引explain时会再提到。1.3 分页查询与深分页的初步优化分页语法很基础limit offset, row_count或者写成limit row_count offset offset。比如每页10条第3页就是limit 20, 10。问题在于这个“偏移量”是MySQL先扫出前offset row_count行再把前offset行丢掉。偏移量越大扫描的无效行就越多典型的深分页问题。举个例子order by id limit 1000000, 10听起来是只取10条但MySQL实际扫描了1000010行然后丢掉前100万行。表一大这个查询就慢得没法看。我早期做后台列表页就踩过这个坑当时表里才几十万条数据翻到后面几页已经明显卡顿。基础阶段的优化思路有两个。一个叫“延迟关联”先用覆盖索引后面会讲快速定位到目标行的主键ID再用主键去关联完整数据。另一个思路是“seek分页”也就是记住上一页最后一条记录的ID下一页直接where id 上一页最大id order by id limit 10。这个写法在数据量大、排序字段又有索引时非常高效缺点是翻页只能顺序翻没法直接跳页。对于大多数业务场景用“seek分页”反而比跳页更符合用户习惯。select *这个习惯也建议改掉。只查你需要的字段不仅减少网络传输还能给“覆盖索引”留出优化空间。写查询前先想想这列数据我是真要用还是只是“顺手拿一下”顺手拿的字段往往就是拖慢查询的元凶。2. 修改与删除一条SQL改动全表数据之前先想清楚这一节讲的是update和delete内容不复杂但风险比查询高出一个量级。查询写错了顶多是查得慢修改删除写错了数据就没了。我见过不少新人接手项目后第一句update就把状态字段全改了幸好有备份才没酿成大祸。2.1 update的完整语法与安全习惯完整的update语法长这样update user set nickname 张三, status 1 where id 10086;几个注意点。第一set后面多个字段用逗号分隔不是and。第二where是安全线没有where的update会更新整张表。第三MySQL的update还支持order by和limit比如update user set status 1 order by create_time desc limit 10只更新最新创建的10条记录这种写法在批量修复数据时很实用。数值字段的更新还有一个隐蔽的坑不要“先查再改”。比如商品库存要增加5有些同学会先select stock from goods where id 1在代码里加5再update goods set stock 新值 where id 1。在并发场景下两个请求同时读到旧值后提交的会把先提交的覆盖掉库存就错了。正确做法是直接update goods set stock stock 5 where id 1。数据库的行锁会保证同一时刻只有一个会话能改这行stock 5是原子操作天然安全。这就是热搜词里“mysql中int5”的实际应用场景。习惯上我每次写update之前都会先跑一条等价的select count(*)或select id确认影响范围对不对。比如-- 先看 select id, status from order where status pending and create_time 2025-01-01; -- 确认无误后再改 update order set status cancelled where status pending and create_time 2025-01-01;线上环境改数据之前如果影响行数很大优先把受影响的数据备份成一张临时表create table order_bak_20250101 as select * from order where 条件。这一步几秒钟的事但真出了问题救命的稻草就是它。2.2 设置默认值为0和批量更新热搜词里有一个“mysql设置默认值为0”建表时直接用default声明就行create table user ( id int primary key auto_increment, score int not null default 0, status tinyint not null default 0 );如果表已经建好了要用alter table改默认值alter table user alter column status set default 0;这里有个容易误解的地方修改默认值只影响“之后插入”的数据已经存在的行不会自动变成0。如果想让历史数据也变成0需要单独跑一次update。经常有同学以为改了默认值老数据就变了结果上线后一堆脏数据。批量更新在业务里也很常见比如把所有超过一年未登录的用户标记为“流失”update user set status lost where last_login_at date_sub(now(), interval 1 year);注意这类“批量”更新往往影响行数大执行时要避开业务高峰期。大事务也会带来锁的问题这一点我们后面讲事务和锁的时候再展开。2.3 update与子查询看起来很顺报错很疼想用子查询来更新同一个表的时候会撞上一个经典报错“You cant specify target table user for update in FROM clause”。举个例子很多人想给“比平均分高的用户”加个标记会这么写update user set is_high_score 1 where score (select avg(score) from user);MySQL不许你在update同一个表时在子查询里直接引用这个表。解决办法很简单包一层临时表update user set is_high_score 1 where score (select avg_score from (select avg(score) as avg_score from user) t);多表更新是另一个常用技能语法是update后面跟join。比如把订单表里的user_name临时字段同步成用户表的当前昵称update order o join user u on o.user_id u.id set o.user_name u.nickname where o.create_time 2025-01-01;这个语法写起来直观执行效率也比逐条update高很多。同样道理delete也可以多表关联删除比如删除没有任何订单的“僵尸用户”delete u from user u left join order o on u.id o.user_id where o.id is null;2.4 delete与truncate的界限delete from不加where和update不加where一样都是灾难性的。区别在于delete是逐行删除InnoDB会记录每一行的删除操作所以可以配合事务回滚truncate table则是把整个表重建速度快得多但它是DDL操作会隐式提交不能回滚并且会重置自增ID。业务代码里基本不需要用到truncate它更适合开发环境清空表数据用。删除表数据前如果表很大不建议一次性delete因为一个大事务会持有大量行锁容易把其他写入请求堵住。可以考虑分批删除比如每次delete ... where id ? and id ? limit 1000循环几轮把数据删完。这种操作看起来慢但稳不至于把线上业务拖死。我后来养成了一个习惯线上执行任何update/delete都要把原始where条件从select换成update/delete并且先把“影响行数”这一项确认清楚。MySQL客户端在执行更新语句时会显示Rows matched: X Changed: Y看到Changed的数字比预期大很多先别急着commit赶紧确认一下是不是条件写宽了。3. 多表查询精髓join到底在做什么热搜词里“mysql数据库join含义”热度不低这说明join是很多人的知识盲区。其实join没那么玄乎它就是把两张表按照条件“拼”成一张临时的宽表。搞懂它很多业务查询会顺手很多。3.1 从直观理解到三种连接先举个生活化的例子。有一张“用户表”存用户ID和昵称有一张“订单表”每条订单带着用户ID。你想看每个订单是谁下的总不能查完订单再一条条查用户吧用join一次搞定select o.order_id, o.user_id, u.nickname from order o inner join user u on o.user_id u.id;这里的on o.user_id u.id就是“拼表条件”。inner join的意思是只保留两边都能匹配上的行某个用户的订单会在结果里出现多少条取决于他有多少个订单。如果某张订单的用户已经删了虽然一般有外键约束不会发生这条订单就不会出现在inner join的结果里。left join左连接则以左边那张表为准右边表匹配不上就补NULL。比如select u.id, u.nickname, o.order_id from user u left join order o on o.user_id u.id;这样每个用户都会出现哪怕他没有订单那order_id就是NULL。这个写法在“查没买过东西的用户”这类场景里特别有用left join之后再where o.id is null就能精准筛出右边表不存在的记录。right join用得少因为把表顺序调换一下right join就可以改写成left join可读性还更好。join还有一个特性要注意如果在右边的表里有多个匹配行左边的那一行会被复制多次。比如一个用户下过3笔订单left join之后这个用户就会出现3行大家统计用户数时容易重复计数本质原因就在这里。3.2 三个高频业务场景第一个场景是“查每个用户的最新一笔订单”。一个用户有多条订单想取出每个用户最新那条的完整信息。有些人的第一反应是group by user_id再加max(create_time)但如果还想拿到order_id、金额等字段直接用group by会拿不到对应行的完整数据。标准做法是“先取最新时间再join回去”select u.id, u.nickname, t.order_id, t.amount from user u join ( select user_id, max(create_time) as max_time from order group by user_id ) m on m.user_id u.id join order t on t.user_id m.user_id and t.create_time m.max_time;这种写法叫“子查询join”比窗口函数row_number() over更容易理解也是面试里常见的考点。第二个场景是“统计每个用户的订单数量”。要注意count的字段如果统计的是关联表的主键结果才是准确的select u.id, u.nickname, count(o.id) as order_cnt from user u left join order o on o.user_id u.id group by u.id, u.nickname;left join保证没有订单的用户也会出现count(o.id)只统计非NULL的订单ID所以没订单的用户是0。如果偷懒写count(*)没有订单的用户会变成1因为你把左边表那行也算进去了。第三个场景是“查完全没关联的记录”上面提到过用left join加is null。顺带提一句not in也能做但not in的子查询结果里有NULL时整个查询会不返回任何行这个坑非常隐蔽。能用left join解决的我就不会优先用not in。3.3 on与where两个条件的生效时机不一样left join里面on后面的条件是对“右边那张表”做匹配用的。在on里加o.status paid不会让左边用户表少一行只是影响右边订单表能不能匹配上匹配不上显示NULL。但如果你在where里写o.status paid则是在结果集生成之后再做过滤不满足的用户行会被直接过滤掉left join的左表主行防护作用就没了。看一个对比-- on里过滤所有用户都在只是没付款订单的人order_id为NULL select u.id, o.order_id from user u left join order o on o.user_id u.id and o.status paid; -- where里过滤只有支付过订单的用户才出现在结果里 select u.id, o.order_id from user u left join order o on o.user_id u.id where o.status paid;两种写法业务语义完全不同。想把“所有用户及已支付订单”列出来用第一种只关心“有支付订单的用户”用第二种但这种可以直接inner join。理解on和where的生效时机能帮你少写不少逻辑错误的SQL。4. 事务、隔离级别与锁并发场景的安全底线基础一里建的表可能单机一个人在操作所以不会感觉到并发问题。但一旦上了项目多个请求同时读写同一条数据没有事务和锁的保护数据就会变得一团糟。4.1 为什么需要事务转账场景的启示想象一个转账场景A账户扣100元B账户加100元。这两步必须捆绑在一起要么都成功要么都失败。如果扣了A的钱但给B加钱时程序崩了钱就凭空消失了。事务就是干这个的。事务有四个特性原子性、一致性、隔离性、持久性合起来叫ACID。原子性保证“扣钱加钱”是一个整体一致性保证转账前后总额不变隔离性保证并发事务之间互相干扰可控持久性保证提交后的数据不会丢。MySQL里手动开启事务很简单start transaction; update account set balance balance - 100 where id 1; update account set balance balance 100 where id 2; commit; -- 确认无误提交 -- rollback; -- 发现问题回滚注意一条update本身默认是自动提交的start transaction之后后续的SQL才在同一个事务里。如果你的客户端工具里执行了start transaction却忘了commit/rollback连接一直占着事务行锁也一直不释放后面同一条数据的更新就会一直等锁——这就是最常见的“锁表”诱因。4.2 隔离级别鱼和熊掌的取舍事务并发会引出三个问题脏读、不可重复读、幻读。用大白话解释一下。脏读事务A读到事务B还没提交的数据。如果B后来回滚了A就拿着一个“假数据”做后续业务问题很大。不可重复读事务A里两次select同一行结果不一样因为事务B在这期间把这条数据update并提交了。典型场景是先读账户余额做判断再更新中间余额被人改了判断就失效了。幻读事务A按条件查询第一次查到5条第二次再查变成10条因为事务B插入了新数据。重点在“多出来几行”像幻觉一样。数据库通过“隔离级别”来决定怎么取舍。标准隔离级别从低到高有四种我直接给一个速查表隔离级别脏读不可重复读幻读说明读未提交可能可能可能基本没人用读已提交不可能可能可能很多数据库默认级别可重复读不可能不可能可能MySQL默认级别串行化不可能不可能不可能并发性能差MySQL的默认隔离级别是“可重复读”也就是说在同一个事务里多次select同一批数据结果是一致的。MySQL还通过“间隙锁”机制在可重复读下把大部分幻读问题也挡住了但理论上它仍然不是完全杜绝。查看和修改隔离级别select transaction_isolation; set session transaction isolation level read committed;实际项目中大多数互联网业务用“读已提交”也够了还能减少锁冲突。但既然MySQL默认是可重复读业务里就要注意长事务的问题因为间隙锁的范围可能比想象中大进而影响并发写入。4.3 锁表问题排查与预防“锁表”是很口语化的说法本质是指一个事务持有了某些行/表的锁还没释放后面的事务在等锁表现为SQL一直卡住迟迟不返回。我实际遇到过的情况是这样的某个同事在图形化工具里执行了update order set status 1 where id 123但他忘了点击“提交事务”连接一直挂着。等于这行数据的锁一直被攥在手里线上其他订单都要更新这行全部卡在“等待锁”状态。前台用户开始反馈下单失败后台update全部超时。排查手段不复杂。第一步看当前有哪些活跃连接在干什么show processlist;重点看state列是不是出现“Waiting for table metadata lock”或者“Waiting for lock wait timeout”之类的字样。第二步查information_schema.innodb_trx看有没有长时间未提交的事务select * from information_schema.innodb_trx;如果发现某个事务的trx_started时间很久之前它大概率就是“锁源”需要确认是否还在正常工作。是的话可以联系负责人提交或回滚实在联系不上、又是明显异常的长事务就只能kill掉对应连接。注意kill之前要确认这个事务没有在跑关键业务否则可能造成数据不完整。预防锁表我在团队里反复强调三件事第一事务一定要短别在事务里做耗时的外部HTTP调用、批量文件解析这些时间都算在锁的持有时间里第二update/delete的条件一定要带索引条件没索引时InnoDB可能锁很多行甚至全表锁范围瞬间放大第三大事务拆分比如一次处理1000条数据的逻辑拆成100次、每次10条整体提交锁持有的时间会短很多。5. 存储过程与触发器封装逻辑可以别滥用讲完事务和锁再说说很多人问的存储过程、触发器和内置函数。它们的核心价值在于“把重复逻辑封装在数据库里”省得在应用层一遍遍重复写。但它们的缺点也很突出调试困难、版本管理难、迁移到其他数据库基本要重写。我的建议是基础阶段必须懂、能看、能写简单的但正式项目里要克制使用。5.1 常用内置函数与流程控制日常SQL里常见的函数可以分成几类我挑最常用的说。字符串类concat拼接、substring截取、replace替换、upper/lower大小写。数值类round四舍五入、abs绝对值、floor向下取整。日期类now()当前时间、curdate()当前日期、date_format()格式化日期、datediff()计算日期差。流程控制类if(expr, a, b)、case when、ifnull(a, b)。写一个实用组合把时间格式化成“年月日”输出并把没有备注的显示为“暂无备注”select id, date_format(create_time, %Y-%m-%d) as create_date, ifnull(remark, 暂无备注) as remark from user;case when是逻辑控制的核心比如把订单状态码转成中文select order_id, case status when 0 then 待支付 when 1 then 已支付 when 2 then 已发货 else 未知 end as status_text from order;这些函数不复杂但能写出来很多报表统计SQL就顺手了。5.2 存储过程声明、变量、参数与delimiter存储过程可以理解成“数据库里的函数”把一段SQL逻辑打包用call调用。新手第一次接触时最困惑的就是delimiter。为什么需要它因为MySQL的命令行客户端默认用分号;作为一条语句的结束符而存储过程体内部会有多条以分号结尾的SQL。如果不先把结束符改掉客户端一看到分号就认为命令结束了后面的内容就乱了。看个完整例子创建一个“按用户ID统计订单数量”的存储过程delimiter $$ create procedure get_order_count_by_user(in uid int, out cnt int) begin select count(*) into cnt from order where user_id uid; end$$ delimiter ;in表示输入参数out表示输出参数into cnt是把查询结果赋值给输出变量。调用方式是这样的set cnt 0; call get_order_count_by_user(1, cnt); select cnt;cnt是用户会话变量select cnt就能看到统计结果。如果希望在存储过程内部用中间变量用declare声明比如declare v_total int default 0;配合set或select ... into赋值。存储过程的优点不少减少应用和数据库之间的网络交互业务逻辑可以集中管理某些复杂统计在数据库内执行可能比应用层多次查询更快。缺点同样明显不好调式、动态SQL写起来费劲、数据库迁移时成本高、权限管理麻烦。所以我的态度是面试要会写能看懂别人的存储过程但生产环境优先把业务逻辑放在应用层除非实在有性能诉求或历史包袱。5.3 触发器自动执行的隐患触发器是一个在表发生insert/update/delete时自动执行的逻辑块。比如我想在用户表插入新用户后自动往日志表写一条记录delimiter $$ create trigger trg_user_insert after insert on user for each row begin insert into user_log(user_id, action, create_time) values (new.id, insert, now()); end$$ delimiter ;new代表插入后的新行old代表更新前的旧行。insert触发器只能用newdelete触发器只能用oldupdate两者都能用。比如new.status是新状态old.status是旧状态。触发器的最大问题在于“隐式”。你执行一条insert还以为只做了那一件事但实际上数据库悄悄又执行了别的东西。如果触发器里再写了复杂逻辑或者级联调用另一个存储过程排起错来非常痛苦线上问题定位难度直线上升。而且触发器执行失败会直接导致主操作失败业务上很难感知到原因。所以还是那句能用应用层代码解决的就别用触发器。基础阶段能看懂、能维护即可不建议自己往生产库上添加。6. 索引入门为什么加了索引查询还是慢热搜词里“mysql创建索引”“mysql性能调优”一直很火。索引是MySQL性能优化里最核心的一环这一节只讲基础但足够你应付日常开发中90%的慢查询问题。6.1 索引是什么一本书的目录你可以把MySQL的索引理解为书前面的目录。没有目录时想找某个知识点只能一页页翻这叫全表扫描有了目录先定位页码直接翻过去速度快得多。InnoDB存放索引的数据结构是B树一个常见理解是数据被组织成有序的树状结构查找效率从O(n)降到接近O(log n)。索引不是越多越好。每建一个索引MySQL在写入数据时都要额外维护这个索引结构相当于每次改数据都要多写几份“目录”。所以索引是一种“用空间换时间、用写性能换读性能”的手段。一般原则是where条件里高频使用的字段、join的连接字段、order by/group by的字段优先考虑加索引区分度低比如性别这种只有两三个值的列的字段加了索引也可能不走没意义。语法很简单create index idx_user_phone on user(phone); alter table user add index idx_user_phone (phone);多条索引时考虑建“复合索引”比如(status, create_time)。注意复合索引遵循“最左前缀”原则where status ?能用到它where create_time ?用不到where status ? and create_time ?完美命中。优先把筛选能力强、使用频率高的字段放最左边。6.2 explain学会看懂执行计划判断一条SQL到底有没有走索引别靠猜用explain看执行计划explain select * from user where phone 13800138000;输出里重点看几个字段type、key、rows、Extra。type是一个很重要的指示器常见的值从好到坏大概是const、eq_ref、ref、range、index、ALL。const说明按主键或唯一索引精准命中一行非常快ref说明用了普通索引等值匹配也很快range说明走索引但用了范围扫描ALL是全表扫描慢查询的首要大坑。key显示实际用到的索引名rows是预估扫描行数数字越小越好。Extra里的Using filesort代表排序没走索引Using temporary代表用了临时表这两种情况在大数据量下都要警惕。一个加索引前后的案例。假设user表有10万条数据phone列没有索引执行explain select * from user where phone 13800138000; -- typeALL, rows100000这是全表扫描。创建索引后再执行同一条SQLcreate index idx_user_phone on user(phone); explain select * from user where phone 13800138000; -- typeref, rows1type从ALL变成ref扫描行数从10万变成1查询速度肉眼可见的提升。这就是索引最直观的价值。6.3 常见的索引失效场景即便建了索引SQL写法不对也会让索引失效这是新手特别容易踩的坑。我列几个高频场景。第一对索引列做函数运算。比如where date(create_time) 2025-01-01因为对字段做了date()函数处理索引就无法使用。正确写法是用范围条件where create_time 2025-01-01 and create_time 2025-01-02让索引可以利用起来。第二隐式类型转换。字符串字段存手机号却用数字去匹配比如where phone 13800138000MySQL会把字段转成数字再比较索引失效。解决办法就是保持类型一致写成字符串。第三前导模糊查询。like %abc在前面用了通配符MySQL不知道从哪个值开始匹配索引没法用like abc%是可以走索引的。业务上如果非要做“包含”查询建议上全文索引或者引入搜索引擎而不是硬扛。第四复合索引不满足最左前缀。前面说过复合索引(status, create_time)你只拿create_time去查用不上索引。第五or条件里有一个字段没索引。比如where phone xxx or nickname yyy如果nickname没有索引整个查询可能退化成全表扫描。与其用or不如拆成两个查询后union合并结果。索引失效不算报错MySQL只是付出了全表扫描的代价。所以线上慢查询优化时先用explain确认一下到底是“没有索引”还是“有索引没用上”对症下药。7. 高频报错与排查技巧速查最后这部分聊几个大家经常搜的报错和排查思路。数据库报错不可怕可怕的是不知道去哪里查。7.1 ERROR 2002socket连接失败热搜词里有个非常典型的报错ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock。这个报错主要出现在Linux上意思是客户端想通过socket文件连接本地MySQL但连不上。最常见的原因是MySQL服务没启动先检查服务状态systemctl status mysqld systemctl start mysqld也有可能是socket文件路径不一致。MySQL的socket文件路径在配置文件里通常叫/tmp/mysql.sock或/var/lib/mysql/mysql.sock。如果你编译安装过多个版本客户端和服务端的socket路径对不上就会出现这种问题。排查方式ps -ef | grep mysqld看进程参数或者在连接时显式指定host和port。7.2 初始密码与root权限问题新装完MySQL经常要面对“初始密码是什么”的问题。用Linux方式安装时临时密码一般写在日志里grep temporary password /var/log/mysqld.log拿到临时密码登录后再alter user rootlocalhost identified by 新密码;。如果忘了密码一个通用的思路是配置里加skip-grant-tables重启服务免密进入后手动重置密码再把配置项去掉重启。这个方法能解决本地库的燃眉之急但生产环境不建议随便用因为跳过权限检查极其危险。另外MySQL 8.0默认的密码校验策略比较强要求密码同时包含大小写字母、数字和符号。不喜欢的话可以临时降低校验规则set global validate_password.policy LOW;然后改完密码再调回来。网上有大量资料这里不展开但要知道这个机制的存在。7.3 连接层的报错SSL、连接池、驱动版本连接数据库时报SSL相关的错也挺常见。Java的JDBC连接串里经常会看到useSSL和sslMode这两个参数让人犯迷糊。简单理解useSSLtrue表示启用SSL加密连接sslMode是更细粒度的控制比如require要求必须加密verify_certificate还需要验证服务端证书。本地开发连测试库时如果MySQL没配好SSL证书建议直接把useSSLfalse省得给自己找麻烦生产环境再按安全要求配置。连接池报错里高频的是Too many connections意思是连接数打满了。调大max_connections能缓解但更要从源头排查连接池最大数量是不是配太高了程序里有没有正确归还连接有没有慢查询长期占着连接show variables like max_connections;和show status like Threads_connected;是常用排查入口。还有一个相对新的坑代码里用的MySQL驱动版本太旧连8.0以上的库时可能会报警告或错误比如某些框架会提示“需要MySQL 8.4或更高版本”。遇到这种先检查JDBC驱动版本、mysql-connector版本升级到和数据库大版本匹配的驱动即可不要盲目调整数据库配置。7.4 报错速查表报错关键词常见原因快速处理思路ERROR 2002 ... socket服务未启动 / socket路径不一致启动服务检查配置文件路径指定host/port连接ERROR 1045 ... Access denied用户名、密码或权限不对核对账号密码检查grant权限ERROR 1146 ... Table doesnt exist表名拼写错或选错库show tables;确认表名ERROR 1062 ... Duplicate entry主键或唯一索引冲突查重复数据确认是否应做更新而非插入ERROR 1205 ... Lock wait timeout锁等待超时查information_schema.innodb_trxkill阻塞事务ERROR 1153 ... packet too large单条SQL超过max_allowed_packet调整max_allowed_packet或拆分SQLAuthentication plugin caching_sha2_password客户端驱动不认识新版认证插件升级客户端驱动或改回旧认证插件不推荐Too many connections连接数打满查连接来源调大max_connections优化慢查询MySQL基础二写到这里内容量已经很大了。你不需要一次全背下来我的建议是先把三件事变成肌肉记忆写任何修改删除语句之前先确认“影响了什么”遇到慢查询先explain看执行计划线上任何长事务、大事务都可能是锁的源头能拆就拆、能短就短。这三条比记一百条面试题都管用。至于主从复制、备份恢复、更细的性能调优等到你真正需要的时候再深入基础阶段先把眼前的SQL写稳、写对就已经跑赢很多人了。
