直奔主題

有四張表需要關聯查詢
ticket_reserve ：票品預約表
program ：節目表
program_scene ：節目下的場次表
city ：城市表

需求：預約記錄列表 （需包含預約的場次，場次所屬的城市，場次所屬的節目）

select 
  `ticket_reserve`.*, 
  `ticket_reserve`.`created_at` as `tcreated_at`, 
  `ticket_reserve`.`id` as `rid`, 
  `program`.*, 
  `program_scene`.*, 
  `city`.* 
from 
  `ticket_reserve` 
  left join `program` on `program`.`uuid` = `ticket_reserve`.`program_id` 
  left join `program_scene` on `program_scene`.`uuid` = `ticket_reserve`.`scene_id` 
  left join `city` on `city`.`code` = `ticket_reserve`.`city_id` 
where 
  `reserve_mode` in (0, 2) 
  and `resserve_status` != 3 
order by 
  `ticket_reserve`.`created_at` desc 
limit 
  10 offset 0;

5秒。。。。。。。。。。。。。扎心了

一定有問題，先看下索引吧。

program表沒有問題，與主表關聯的uuid字段建立了唯一索引

program_scene表 uuid字段 也是唯一索引

city表 code字段 也是唯一索引

ticket_reserve 只有主鍵

不應該啊，索引都沒有問題，難道是數據量太大了？

最多的數據也沒有超過5000
那么是什么導致速度回這么慢呢

explain之后 發現一個索引也沒有用到

查看ticket_reserve表結構，發現所有的行的字符集都是utf8mb4,而其余三張表都是默認的utf8字符

先改為utf8試試(null也會影響到性能，一并優化掉)

alter table 
  ticket_reserve modify `program_id` varchar(255) NOT NULL DEFAULT '' comment '關聯節目ID'; 
alter table 
  ticket_reserve modify `scene_id` varchar(255) NOT NULL DEFAULT '' comment '關聯場次ID'; 
alter table 
  ticket_reserve modify `city_id` varchar(255) NOT NULL DEFAULT '' comment '關聯城市ID';

果然是字符集不同影響到了索引

這就正常多了 10毫秒 整個提升了544倍 ！