世界を見る
データベース：一度に一つだけ
「インデックス最適化 / トランザクション / チューニング」という切り方はしません —— それだと底牌が「選択率に注意、ロックに注意」にしかなりません。ここで切っているのは複合インデックスの列順、UPDATE 一本が実際に何をロックしたか、OFFSET があの一歩で何をしているか。一つにつき一つだけです。
このプロンプト集は今のところ简体中文だけです。
使い方
これは学習型です：導いてくれますが、答えられなくなるまで追い詰めることはしません。詰まったらまずどの層で詰まっているか（聞いたことがない / 知っているが理由が分からない / 分かるが使えない）を訊いてから、何を渡すか決めます。同じ点で二回導いても通じないときだけ直接説明し、そのあと自分の言葉で言い直させます。
既定では MySQL / InnoDB で話します —— この分野の落とし穴は半分が実装の詳細で、クラスタインデックス・二次索引からの再検索・ギャップロックは他では事情が違います。PostgreSQL などでも構いません。最初の一言でどれを使っているか言えば、それに合わせて話し、結論が変わるところを指摘してくれます。
始め方
- 一つ選び、開いて、プロンプトをコピーします。
- 新しい空のチャットに貼り、最初にどの製品のどのバージョンかを言います（言わなければ MySQL 8 として扱われます）。
- あとは何も言わず、最初の質問を待ちます。
途中でいつでも使える四つの合言葉
跳过すぐ次の幕へ换个说法ここを別の角度で言い直して直说吧完全な答えを言って、そのあと復唱させて复盘すぐ締めのカードへ
三つの落とし穴
- 末尾の底牌を先に読まないこと —— あの「よくある思い違い」の欄が、各問の答えそのものです。
- 数字を求められる覚悟を。「少し速くなる」「IO が減る」はその場で遮られます：何行？何回？何倍？ 数字の出ない結論は暗記です。
- 褒め始めたら「褒めるな」の条を指摘してください。導くことと甘やかすことは別です。
まず複合インデックスの回から。ここの土台で、「ロックはインデックスの記録に付く」「なぜこんなに行を読むのか」はどちらもその一文に寄りかかっています。本番で並行性に噛まれているなら「読んでから書く」、クエリが遅いなら実行計画の回から。
インデックス
联合索引的顺序
(user_id, status) 这个索引，单查 status 为什么用不上？
它为什么没走索引
索引明明建了，它就是不走 —— 是写废了，还是它算过了？
一次查询读了几棵树
一次查询到底读了几棵树、回表几次？
トランザクションとロック
隔离级别各挡住了什么
RR 下读到余额 100，然后 UPDATE balance = balance - 10 —— 扣完是多少？
一条 UPDATE 锁了什么
UPDATE ... WHERE 一个没索引的列 —— 这时候「行锁」还是行锁吗？
先查再改，为什么会丢
「包进事务里不就行了」——事务到底挡住了什么？