次のクエリにより、データベース環境で CPU 使用率が高くなり、待ち時間が長くなります。 クエリのパフォーマンスを向上させるためにさまざまな種類のインデックスを使用してみましたが、残念ながらどのインデックスもパフォーマンスの向上に役立ちませんでした。同じ結果を得るためにクエリを書き直すという提案はありますか。
このインデックスは view_mats: INDEX(mngy, nonUnixjdjf) に適しています。つまり、trip_dsty の場合: INDEX(mngy, jdjf)。
view_mats
INDEX(mngy, nonUnixjdjf)
trip_dsty
INDEX(mngy, jdjf)
そして、(おそらく) idx_n1 を削除します。これにはインデックスの先頭しか含まれていないためです。
idx_n1
(私は列ストアに完全に精通しているわけではありません。上記のアドバイスは InnoDB インデックスに関するものであり、ここにも当てはまる可能性があります。)
一般に、Float および Double の (m,n) は役に立たず、丸めエラーが発生する可能性があります。 double(20,10) はおそらくプレーン double または DECIMAL(20,10) である必要があります。
(m,n)
double(20,10)
double
DECIMAL(20,10)
LIMIT 10000 - 本当にそれだけの行をクライアントに配信しましたか?あまりにも多くの作業を行うのはパフォーマンスの問題でもあります。
LIMIT 10000
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
このインデックスは
view_mats:INDEX(mngy, nonUnixjdjf)に適しています。つまり、trip_dstyの場合:INDEX(mngy, jdjf)。そして、(おそらく)
idx_n1を削除します。これにはインデックスの先頭しか含まれていないためです。(私は列ストアに完全に精通しているわけではありません。上記のアドバイスは InnoDB インデックスに関するものであり、ここにも当てはまる可能性があります。)
一般に、Float および Double の
(m,n)は役に立たず、丸めエラーが発生する可能性があります。double(20,10)はおそらくプレーンdoubleまたはDECIMAL(20,10)である必要があります。LIMIT 10000- 本当にそれだけの行をクライアントに配信しましたか?あまりにも多くの作業を行うのはパフォーマンスの問題でもあります。