---
fuzzed_data:
  title: Fuzzed Data
  summary: Shiba doesn't know the size of <b>{{table}}</b>.  For these purposes we set the table size to <b>{{table_size}}</b>.
  description: |
    We're not sure how much data this table will hold in the future, so we've pretended
    there's 6000 rows in it.  This can lead to a lot of false positives. To
    improve results, please give shiba your index statistics.
  level: info
possible_key_check:
  title: Oddly reported possible keys
  description: |
    MySQL reported that it had keys it could have used, but elected not to use them.
    Shiba checked each of the possible keys and returned the results from the best
    key possible.  Sometimes "possible_keys" will be inaccurate and no keys were possible.
  level: info
access_type_const:
  title: One row
  summary: The database only needs to read a single row from <b>{{table}}</b>.
  description: |
    This query selects at *most* one row, which is about as good as things get.
  level: success
access_type_ref:
  title: Indexed
  summary: The database reads {{ cost }} rows in <b>{{ table }}</b> via the <b>{{ key }}</b> index ({{ key_parts }}).
  description: |
    This query uses an index to find rows that match a single value.  Often this
    has very good performance, but it depends on how many rows match that value.
  level: success
access_type_range:
  title: Indexed
  summary: The database uses a "range scan" to read more than {{ cost }} rows in {{ table }} via the <b>{{ key }}</b> index ({{ key_parts }})
  description: |
    This query uses an index to find rows that match a range of values, for instance
    `WHERE indexed_value in (1,2,5,6)` or `WHERE indexed_value >= 5 AND indexed_value <= 15`.
    It's very hard to estimate how many rows this query will consider in production, so we've
    upped the cost of this query.
  level: info
access_type_tablescan:
  title: Table Scan
  summary: The database reads <b>100%</b> ({{ table_size }}) of the rows in <b>{{ table }}</b>, skipping any indexes.
  description: |
    This query doesn't use any indexes to find data, meaning this query will need to evaluate
    every single row in the table.  This is about the worst of all possible worlds.

    This *can* be fine if, say, you're querying a tiny table (less than ~500 rows),
    but be aware that if this table is not effectively tiny or constant-sized you're entering
    a world of pain.
  level: danger
limited_scan:
  title: Limited Scan
  summary: The database reads {{ query.cost }} rows from {{ query.table }}.
  description: |
    This query doesn't use any indexes to find data, but since it doesn't care about
    ordering and it doesn't have any conditions, it only ever reads {{ query.cost }} rows.
  level: info
ignored:
  title: Ignored
  summary: This query matched an "ignore" rule in shiba.yml.  Any further analysis was skipped.
  description:
  level: info
index_walk:
  title: Index Walk
  description: |
    This query is sorted in the same order as the index used, which means that the database
    can read the index and simply pluck {LIMIT} rows out of the index.  It's a very
    fast way to look up stuff by index.
  level: success
retsize_bad:
  title: Big Results
  summary: The database returns {{ return_size }} rows to the client.
  level: danger
retsize_good:
  title: Small Results
  summary: The database returns {{ return_size }} row(s) to the client.
  level: success