# pair-1a レビュー 2021/03/25

###### tags: `ペアレビュー`

### ishihara

- (?)date_format()でもインデックスがきいたのはなぜ？
- 年を抽出している場合は、前方インデックスになる？
- (?)group by でもインデックスがきく？
- YEAR()関数あり

- 誕生年 (birth_date の 年のみ) ごとの従業員の人数を取得してください。
- インデックスは使われていたが、読み込み行数は一緒だった
- explainのrowsは読み込み行数
- (?)フルインデックススキャンとフルテーブルスキャンの差は？
- (ishihara)
- (?)group by の場合のインデックスの使われ方は？
- (nakano)
- 最も若い従業員のリストを取得してください。 (最も誕生日が新しい社員)
- ishiharaの結果速すぎる？
- 実行時間の内訳詳しく見る (ishihara)
- filesortは遅い？
- EXPLAIN の出力結果をもうちょい知っておく必要がある、、
- イニシャルがX.Xの従業員一覧を取得してください。
- last_nameとfirt_nameのインデックスのうち、last_nameしか使われなかった
- → last_nameの方がカーディナリが大きいから？ (要調査)
- furukawa-san
- 実行速度比較
- last_name only
- first_name only
- count(DISTINCT last_name)で件数分かりそう

### nakano

- employees テーブルを用いて、1990 年の 4 月に雇用された従業員一覧を取得してください。
- employees テーブルを用いて、1965 年の 2 月 1 日生まれの従業員を last_name がアルファベット順に並び替えてください。
- 日付と文字列で比較できた
- 日付と日付、日付と文字列の比較あまり結果に変わりはなかった
- ただし、明示的な変更のほうが少し速いらしい
- インデックス複数貼った場合でも、どれか一つしか使われない！
- インデックス複数貼った場合、どれを使うのかの判断で遅くなる？ (要調査)
- employees テーブルを用いて、従業員の last_name の頭文字が 'Mor' で始まる従業員を男女別に emp_no 順で表示してください。(男性 F を先に表示してください)
- アルファベット順だと F, M のはず → M, F は enumなので、定義した順のorderになっていたっぽい
- 一応調べておきます
- last_name, gender, emp_no の 複合インデックス使われなかった
- genderのカーディナリが低いからっぽい

### furukawa

- 1960 年以降に生まれた社員数を集計せよ
- 1960 年に生まれた社員数を集計せよ
- likeとbetweenはもちろんbetweenが速かった
- 最も女性が入社した年度と人数を取得せよ。
- hire_date_indexが使われなかった → 間にwhereが入っているから
- (?)男女のようなカーディナリの低いカラムにインデックスを貼る？
- index 作成手法どっちがよい？
- しらべておきます
- create or alter

### その他

- (?) インデックス名の命名規則
- nakano-san
- プライマリキーは削除できなさそう
- railsのincludes -> クエリの使い分けをしてくれる
- nakano調査
- railsのdirty
- オブジェクトの状態を監視してくれる
- いったん不整合なデータを受け入れる -> 後で確認
- ActiveRecordがdomain,usecase,repository
- DDD -> domainを重視
- rails -> データベースのテーブルを重視

### 次回
複合インデックスまで