検索を高速化するための「インデックス」がメモリ上で処理されているうちは、レコード(ID)が増えても検索速度が目立って低下することはありません。
逆に、良い設計がなされているデータベースであれば、インデックスがあふれるようなことは発生しませんので、レコード(ID)が増えても検索速度が極端に遅くなることはないと考えていただいて結構です。
DBサイズが大きくなると一般的には遅くなります(いろんな条件は関わってきますが)。
データベース中のテーブルには、
検索を高速化するためにインデックス(索引)が作られます。
インデックスがメモリ中で効果的に使われている間は、高速に検索が行われます。
DBサイズが大きくなったときに、下のような状況では検索速度の低下が顕著になります。
o メモリ不足
o テーブル数が多い
o 複雑なSQLによる検索が多い
o 問い合わせ数が多い
初心者ですみません。本当に考えていただきありがとうございます。
ではテーブル数は増やさないし、複雑な検索はないです。ごく単純。
ただIDの数がどんどん多くなるだけでは基本的にあまり変わらない
で理解していいですか?
検索を高速化するための「インデックス」がメモリ上で処理されているうちは、レコード(ID)が増えても検索速度が目立って低下することはありません。
逆に、良い設計がなされているデータベースであれば、インデックスがあふれるようなことは発生しませんので、レコード(ID)が増えても検索速度が極端に遅くなることはないと考えていただいて結構です。
メモリ上で処理というのはパソコンのメモリーを増設すればOKですか?MYSQL Administratorでのグラフでわかることですか?
追記型のテーブルということでしょうか?
過去のデータを削除するタイミングは、あるのですよね?
インデクスを定義していて、「=」条件や範囲条件などのインデクスを有効利用できる検索なら、母体データ件数が増えても極端に性能劣化しません。
しかし、インデクスを活用できずテーブルスキャン(表のデータ部で探す)が発生するような検索では、母体データ件数が増えることで性能も大幅に劣化してしまいます。
また、検索対象データが多い場合で、order by、group by、distinctなどのソートが必要な処理を、インデクスを利用して「作業ファイルを用いたソート」を抑止できるかどうかで、大きく性能さが出ます。
また、インデクスのキーの更新(insert、delete、updateでのキー更新)が頻繁に行われる場合、インデクスが肥大化し効率的にサーチできなくなるため、よい性能を確保したいなら、定期的なインデクスの再構築が必要になります。
過去のデータを削除をしないようにしたいです。ので今はさくさく動いているのですが、レコードが増えて行くと未来が心配になりました。
考えていただきありがとうございました。
メモリ上で処理というのはパソコンのメモリーを増設すればOKですか?MYSQL Administratorでのグラフでわかることですか?