---
# System prepended metadata

title: ISUCON本番

---

# ISUCON本番
## pt-query digestのクエリに対する考察（1回目）
|通し番号|  クエリ |  備考 | 
|----| ---- | ---- |
|1|  SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = '76866cb4-1ec3-4ef7-bb3e-934990c6c962' ORDER BY `timestamp` DESC LIMIT 1\G | N+1|
|2|  SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = 'a3754aba-4099-4243-89d4-5536eab60299' ORDER BY timestamp DESC\G   | N+1 |
|3|  COMMIT\G  |  COMMIT文を使用すると、現行のトランザクションを終了し、トランザクションで実行したすべての変更を確定できる[参考](https://docs.oracle.com/cd/E16338_01/server.112/b56299/statements_4010.htm)  |
|4|  administrator command: Prepare\G  |  SQL文が記載されず、代わりに記載される文言らしい SQLのバージョンに起因?[参考](https://donuts102.hatenadiary.org/entry/20111007/1317998525)|


## alpのアクセスログ集計に対する考察(1回目)
- ~~apiのエンドポイントを見ると /api/condition/{jia_isu_uuid}に対するアクセスがクソ多い傾向がある~~
- 呼び出し回数だけじゃボトルネックかどうか判断できない気がしてきたのでこれもエンドポイントごとに考察する（適当なので違和感とか感じたら修正してください）

| 通し番号 | エンドポイント | 考察 | 
| ---- | ---- | ---- |
| 1 | /api/signout | |
| 2 | /api/user/me | |
| 3 | /api/isu | ~~isu.jia_user_id,isu.jia_isu_uuidへのindex~~ |
| 4 | (POST)/api/isu | データベースの更新 JIAに対してリクエストしてCharacterを取得 |
| 5 | /api/isu/{jia_isu_uuid} | ~~isu.jia_user_id,isu.jia_isu_uuidへのindex~~ |
| 6 | /api/isu/{jia_isu_uuid}/icon| |
| 7 | /api/isu/{jia_isu_uuid}/graph | |
| 8 | /api/condition/{jia_isu_uuid} |~~isu.jia_user_id,isu.jia_isu_uuidへのindex~~ |
| 9 | (POST)/api/condition/{jia_isu_uuid} |  ~~N+1かも </br>INSERTをfor文でやってる クエリ3のコミットがあった~~ トランザクション処理を用いて軽量化済みだった ~~isu.jia_user_id,isu.jia_isu_uuidへのindex~~ |
| 10 | /api/trend | 合計時間が割とおおめ isu.characterへのindex</br> クエリ通し番号2のN＋1|


`(POST)/api/condition/{jia_isu_uuid}`は一定割合リクエストを落としてしのぐらしいが、これに関して減点、failは発生しないらしい

:::info
## Work in Progress

- クエリ1への対処(main.go 466行目付近 11:50～)
  - 直前のクエリにまとめる(たかはし)
  - https://stackoverflow.com/questions/12526194/mysql-inner-join-select-only-one-row-from-second-table
  - これ参考になりそうではある

- クエリ2への対処（main.go 1106あたり）山本

- エンドポイント9のN+１への対処 岡野
:::

## クエリ1への対処

- サブクエリを使う
- `order by timestamp desc limit 1` を `max(timestamp)` で代用

```sql=
select isu.jia_isu_uuid,isu_condition.message,isu_condition.timestamp from isu inner join (select jia_isu_uuid,max(timestamp) as timestamp,message from isu_condition group by jia_isu_uuid) as isu_condition on isu.jia_isu_uuid = isu_condition.jia_isu_uuid where isu.jia_user_id='isucon1'
```

- 構造体 と テーブル が対応していた
- 構造体 と クエリ を対応させたい → 新しく構造体を作った

結果……

