SQL文効率
SQL文効率
1. SQL最適化の原則は、1回の操作で読み込むBLOCK数を最小限に抑えることです.つまり、最短時間で最大のデータスループットに達します.調整不良SQLは通常以下の点から切り込むことができる:1)不良SQLを検査し、書き方に最適化可能なものがあるかどうかを考える2)サブクエリを調べるSQLサブクエリが簡単な接続で書き直すことができるかどうかを考える3)最適化インデックスの使用を調べる4)データベースのオプティマイザを考える2.SELECT*FROM table文の出現を避け、明確に検出するフィールド. 3. SQL文では、where条件でフィルタされたデータベースのレコードが多いほど、位置が正確であればあるほど、where条件は前に移動する必要があります. 4. クエリー時にできるだけインデックスを使用して上書きします.すなわちSELECTのフィールドに複合インデックスを作成し,クエリ時にインデックススキャンのみを行い,データブロックを読み込まない. 5. 条件を満たすレコードがあるかどうかを判断するときはSELECT COUNT(*)とselect top 1文は使用しないことをお勧めします. 6. 内層限定の原則を使用して、SQL文をスペルする時、クエリー条件を分解して分類して、そしてできるだけSQL文の一番奥の層で限定して、データの処理量を減らします. 7. 式はorder by句では絶対に使用しないでください. 8. 関連テーブルからデータを読み込む必要がある場合は、関連テーブルは一般的に7つを超えないでください. 9. INとORの使用に注意し,In集合中のデータ量に注意する必要がある.推奨セットのデータは200を超えません. 10. <><、>で置き換え、>で置き換え、<で置き換え、インデックスを有効に利用できます. 11. クエリー時に余分なデータの読み取りを最小限に抑えるには、余分な列と余分な行が含まれます. 12. 複合インデックスについては、たとえば、複合インデックスを作成するときに列の順序がF 1,F 2,F 3である場合、whereまたはorder by句でこれらのフィールドがインデックスを作成するときのフィールドの順序と一致し、最初の列を含む必要があります.F 1またはF 1、F 2またはF 1、F 2、F 3のみです.インデックスは使用されません.
13. マルチテーブル関連クエリーの場合、書き方は以下の原則に従わなければなりません.これにより、インデックスの構築に有利になり、クエリーの効率が向上します.フォーマットは次のとおりです.
select sum(table1.je) from table1 table1, table2 table2,table 3 table 3 where(table 1の等値条件(=))and(table 1の非等値条件)and(table 2とtable 1の関連条件)and(table 2の等値条件)and(table 2の非等値条件)and(table 3とtable 2の関連条件)and(table 3の等値条件)and(table 3の非等値条件).注意:マルチテーブルクエリ時のfrom後のテーブルの出現順序が効率に及ぼす影響については検討する必要があります. 14. サブクエリの問題.接続方式やビュー方式で実現できる機能については、サブクエリは使用しないでください.例:
(sqlでinを使用しないように削除)
15. WHERE句では、列の4つの演算、特にwhere条件の左側は避け、演算と関数を使用して列を処理することは厳禁です.例えばsubstringはlikeで代用できるところもあります. 16. 文にnot in(in)操作がある場合は、not exists(exists)で書き換えることを考慮し、外部接続を使用して実装するのが最善です. 17.一つの業務過程の処理に対して、物事の開始と終了の間の時間間隔を短くすればするほどよく、原則としてデータベースの読み取り操作を前に完成させ、データベースの書き込み操作を後に完成させ、交差を避ける. 18. カラム関数やorder by,group byなどをあまり多くのカラムに使用しないように注意し、distinctを慎重に使用してください. 19. unionの代わりにunion allを使用して、データベースはunion操作を実行し、まずunionの両端のクエリーをそれぞれ実行し、一時テーブルに配置し、それからソートし、重複したレコードをフィルタします.既知のビジネスロジックがquery Aとquery Bに重複レコードがないことを決定する場合は、unionの代わりにunion allを使用してクエリの効率を向上させる必要があります.
データ更新の効率1.1つの物事では、同じテーブルに対する複数のinsert文が集中して実行されるべきです. 2. 1つのビジネスプロセスでは、insert,update,delete文をできるだけビジネス終了前に実行し、デッドロックの可能性を低減します.
データベース物理計画の効率I/Oの競合を回避するために、データベース物理計画を設計する際に、ORACLEで例を挙げるいくつかの基本原則に従うべきです.Rollback Segmentの分離:Rollback Segmentは独立したTable spaceに置くべきである.System Table-spaceの分離:System Table-spaceにユーザーのobjectを配置することはできません.(mssqlのprimary filegroupではユーザーのobjectを配置できません)
Temp Tablespaceの分離:個別のTemp Tablespaceを確立し、各userにdefault Temp Tablespaceを指定して破片を避ける:ただし、segmentに大量の破片が発生した場合、データを読む時にアクセスするblock数の増加を招く.DML操作が頻繁に発生するsegemengでは破片はできません
完全に避ける.したがって、DML操作を頻繁に行うテーブルと、変化の少ないテーブルを異なるTable spaceに分離する必要があります.以上の原則に従うと,I/O競合が依然として存在することが判明し,データ分離法で解決できる.接続Tableの分離:実際のアプリケーションでよく接続クエリーを行うTableは、I/O競合を減らすために異なるTaclespaceに分離できます.≪パーティションの使用|Use Partition|emdw≫:データ量の大きいTableとIndexに対してパーティションを使用し、異なるTable spaceに配置します.実際の物理ストレージでは、RAIDを使用することを推奨します.ログ・ファイルは別のディスクに格納する必要があります.
1. SQL最適化の原則は、1回の操作で読み込むBLOCK数を最小限に抑えることです.つまり、最短時間で最大のデータスループットに達します.調整不良SQLは通常以下の点から切り込むことができる:1)不良SQLを検査し、書き方に最適化可能なものがあるかどうかを考える2)サブクエリを調べるSQLサブクエリが簡単な接続で書き直すことができるかどうかを考える3)最適化インデックスの使用を調べる4)データベースのオプティマイザを考える2.SELECT*FROM table文の出現を避け、明確に検出するフィールド. 3. SQL文では、where条件でフィルタされたデータベースのレコードが多いほど、位置が正確であればあるほど、where条件は前に移動する必要があります. 4. クエリー時にできるだけインデックスを使用して上書きします.すなわちSELECTのフィールドに複合インデックスを作成し,クエリ時にインデックススキャンのみを行い,データブロックを読み込まない. 5. 条件を満たすレコードがあるかどうかを判断するときはSELECT COUNT(*)とselect top 1文は使用しないことをお勧めします. 6. 内層限定の原則を使用して、SQL文をスペルする時、クエリー条件を分解して分類して、そしてできるだけSQL文の一番奥の層で限定して、データの処理量を減らします. 7. 式はorder by句では絶対に使用しないでください. 8. 関連テーブルからデータを読み込む必要がある場合は、関連テーブルは一般的に7つを超えないでください. 9. INとORの使用に注意し,In集合中のデータ量に注意する必要がある.推奨セットのデータは200を超えません. 10. <><、>で置き換え、>で置き換え、<で置き換え、インデックスを有効に利用できます. 11. クエリー時に余分なデータの読み取りを最小限に抑えるには、余分な列と余分な行が含まれます. 12. 複合インデックスについては、たとえば、複合インデックスを作成するときに列の順序がF 1,F 2,F 3である場合、whereまたはorder by句でこれらのフィールドがインデックスを作成するときのフィールドの順序と一致し、最初の列を含む必要があります.F 1またはF 1、F 2またはF 1、F 2、F 3のみです.インデックスは使用されません.
13. マルチテーブル関連クエリーの場合、書き方は以下の原則に従わなければなりません.これにより、インデックスの構築に有利になり、クエリーの効率が向上します.フォーマットは次のとおりです.
select sum(table1.je) from table1 table1, table2 table2,table 3 table 3 where(table 1の等値条件(=))and(table 1の非等値条件)and(table 2とtable 1の関連条件)and(table 2の等値条件)and(table 2の非等値条件)and(table 3とtable 2の関連条件)and(table 3の等値条件)and(table 3の非等値条件).注意:マルチテーブルクエリ時のfrom後のテーブルの出現順序が効率に及ぼす影響については検討する必要があります. 14. サブクエリの問題.接続方式やビュー方式で実現できる機能については、サブクエリは使用しないでください.例:
select name from customer
where customer_id in (
select customer_id from order
where money>100
)(sqlでinを使用しないように削除)
select name from customer
inner join order on customer.customer_id=order.customer_id
where order.money>10015. WHERE句では、列の4つの演算、特にwhere条件の左側は避け、演算と関数を使用して列を処理することは厳禁です.例えばsubstringはlikeで代用できるところもあります. 16. 文にnot in(in)操作がある場合は、not exists(exists)で書き換えることを考慮し、外部接続を使用して実装するのが最善です. 17.一つの業務過程の処理に対して、物事の開始と終了の間の時間間隔を短くすればするほどよく、原則としてデータベースの読み取り操作を前に完成させ、データベースの書き込み操作を後に完成させ、交差を避ける. 18. カラム関数やorder by,group byなどをあまり多くのカラムに使用しないように注意し、distinctを慎重に使用してください. 19. unionの代わりにunion allを使用して、データベースはunion操作を実行し、まずunionの両端のクエリーをそれぞれ実行し、一時テーブルに配置し、それからソートし、重複したレコードをフィルタします.既知のビジネスロジックがquery Aとquery Bに重複レコードがないことを決定する場合は、unionの代わりにunion allを使用してクエリの効率を向上させる必要があります.
データ更新の効率1.1つの物事では、同じテーブルに対する複数のinsert文が集中して実行されるべきです. 2. 1つのビジネスプロセスでは、insert,update,delete文をできるだけビジネス終了前に実行し、デッドロックの可能性を低減します.
データベース物理計画の効率I/Oの競合を回避するために、データベース物理計画を設計する際に、ORACLEで例を挙げるいくつかの基本原則に従うべきです.Rollback Segmentの分離:Rollback Segmentは独立したTable spaceに置くべきである.System Table-spaceの分離:System Table-spaceにユーザーのobjectを配置することはできません.(mssqlのprimary filegroupではユーザーのobjectを配置できません)
Temp Tablespaceの分離:個別のTemp Tablespaceを確立し、各userにdefault Temp Tablespaceを指定して破片を避ける:ただし、segmentに大量の破片が発生した場合、データを読む時にアクセスするblock数の増加を招く.DML操作が頻繁に発生するsegemengでは破片はできません
完全に避ける.したがって、DML操作を頻繁に行うテーブルと、変化の少ないテーブルを異なるTable spaceに分離する必要があります.以上の原則に従うと,I/O競合が依然として存在することが判明し,データ分離法で解決できる.接続Tableの分離:実際のアプリケーションでよく接続クエリーを行うTableは、I/O競合を減らすために異なるTaclespaceに分離できます.≪パーティションの使用|Use Partition|emdw≫:データ量の大きいTableとIndexに対してパーティションを使用し、異なるTable spaceに配置します.実際の物理ストレージでは、RAIDを使用することを推奨します.ログ・ファイルは別のディスクに格納する必要があります.