SELECT *がSELECT fooよりもはるかに高速なのはなぜですか？

次のような値とハッシュの表を考えてみましょう。

+------------+----------+------+-----+---------+----------------+
| Field      | Type     | Null | Key | Default | Extra          |
+------------+----------+------+-----+---------+----------------+
| id         | int(11)  | NO   | PRI | NULL    | auto_increment |
| val        | char(9)  | NO   |     | NULL    |                |
| val_hashed | char(50) | YES  |     | NULL    |                |
+------------+----------+------+-----+---------+----------------+

次のクエリは0.00秒で終了します。

SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;

ただし、このクエリには3分17秒かかります。

SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1;

クエリの実行中にプロセスリストがstatusとして表示されることがわかりますSorting result。状況は完全に再現可能です。INSERTテーブルで操作を継続的に実行する別のプロセスがあることに注意してください。

クエリよりも具体的なクエリの実行に時間がかかるのはなぜ*ですか？*パフォーマンス上の理由から、クエリは避けるべきだと常に考えてきました。

フレーズORDER BY 1は異なる列を指します。最初にはid、2番目になりvalます。idキーであるため、インデックスが作成されorder by、些細な作業になります。order by valしかし、システムはすべての行によるソート完全なテーブルを取得する必要がありますvalし、それらの行のひとつを選択し、。

両方のクエリを変更するorder by idと、実行時間はほぼ同じになると思います。

クエリのパフォーマンスの違いは、MGによって十分に説明されています。これに対処します。

私は常に、パフォーマンス上の理由からクエリを避けるべきだと常に信じてきました。

select *それ自体に特定の罰則はありません。誤用されると問題が生じます。単一テーブルのクエリでは、問題なく機能します。そのテーブルを20列の別のテーブルに結合し、後でそれぞれに多くの列を持つ5つの他のテーブルに結合を追加します。今、それは問題です。そのため、理由を説明せずに、幅広いバンドエイド「決してXをやる」を教える人々も同様です。