---
# System prepended metadata

title: 2021-03-18 第7回メンターセッション
tags: [Team-2]

---

# 2021-03-18 第7回メンターセッション

## 項目

### SQLの実行時間は以下のどれが正しいのでしょうか？
- わからなかった。
- 記録として保存しておく際には、slowログ
- pt-query-digestを使って資料化

### LIMITが遅い理由
- LIMITとOFFSETを組み合わせた時のみ遅くなる
    - LIMITだけなら遅くなることはない
- インデックスが貼られている列のORDER BYと組み合わせても高速にならない場合もある
    - MySQLはearly look upなので意味がないらしい
    - late row lookup なら効果はある
        - どのタイミングで実際のデータをみにいくかの違い
   
### 課題20 データベースにおけるNULLの扱いについて
- 中間テーブルを作成して全てのテーブルからNULLを削除すべき

### 【複合インデックスについて】
- 誤差は、実行計画が関係しているのではなく、クエリ後のデータの取得の仕方（ある程度の塊のブロックで取り出す）、メモリに載っている/いないが関係している(推察)。
- なお、MySQL/Postgreどちらでも誤差は生じる。
- ちなみに、複合インデックスを行ったクエリの実行条件は、フルスキャンのクエリになるのでインデックスが使われていなかったと思われる。

### マテリアライズドビューの更新タイミングについて

- 定期実行のほうが多い（毎晩とか）
- マテリアライズド・ビューごとリフレッシュするしか無いから、あんまり頻繁にリフレッシュしたくない
- 常に最新が必要なときはビュー、とにかくはやくほしいときはマテリアライズドビュー
- 履歴データ、売上データの集計などは古くてもよいのでマテリアライズドビュー
- もしどうしてもマテリアライズドビューを頻繁にやりたいときは、「トリガー」を設定する（ポスグレ）
- 最近の研究 → Incremental View Maintenance
- テーブルを作ってしまうのと何が違うのか？
    - テーブルはインサートとかアップデートできる → データが壊れてしまう可能性がある
    - メンテナンス性はマテリアライズドビューの方が高い

### SQLのテスト
- ほとんどの人がORマッパーを使ってるので、単体テストの需要がない
- レポジトリ層のテストでSQLが正しいことを担保する
- 検索系のテストであれば、CSVなどに出力してスナップショット的にテストするよりも、ちゃんとアサーションを書いた方が堅牢になる

### エンティティの生成について
- ドメインオブジェクトのメソッドで新しいエンティティが生まれることは不自然
- ドメインサービスもしくはファクトリーで新しいエンティティを生成することが自然
- 履歴を持つようなデータだと、最新データを更新したつもりが古いデータを更新する危険性がある

### RDBのシャーディングについて
- アプリケーション層で把握しておく
    - かなり面倒
- データベースに任せる
    - AmazonのRDS、MongoDBなど
- ハッシュによるシャード先の決定と範囲によるシャード先の決定がある
- レプリケーションの方がシャーディングよりは楽。100万人程度ならレプリケーションでも余裕。
- 複数サーバーにテーブルを分割した場合、どこのサーバーにアクセスするかはアプリケーションが知っている必要がある。
 
###### tags: `Team-2`
