Quote:
書き込み(Insert / Update / Delete)が頻繁に行われているテーブルにOptimizeをかけると、稀にですがテーブル内の情報がおかしくなる場合があった気がするので。
う〜ん。
いくらなんでもそれは、MySQLかファイルシステムに問題があるのでは?
MySQLは3.23でも、テーブル単位のロックは持っているので、Optimize(ロック)中にINSERT/UPDATE/DELETEが来ても処理しないでしょう。
それはともかく、今回のsessionテーブルで一番の問題は、OptimizeよりもIndex破損の方ですね。MYIファイルの方なら、最悪、完全に壊れても復旧可能なので、-a の方を高い頻度で行うべきか?
Quote:
う〜ん。
いくらなんでもそれは、MySQLかファイルシステムに問題があるのでは?
やっぱりそうですかね^^;
「テーブルロックしてるはずなのに、Optimize直後からデータが壊れていた」&「Optimizeは稀にデータを壊す、という情報を聞きかじっていた」ので、Optimizeを悪者にしていました
Quote:
「テーブルロックしてるはずなのに、Optimize直後からデータが壊れていた」&「Optimizeは稀にデータを壊す、という情報を聞きかじっていた」ので、Optimizeを悪者にしていました
ちょっと誤解を招く書き方ですみません。
実際にそういう現象があるのであれば、DBの混雑具合によらず、Optimizeをしない、というのが一番ですね、という意味です。
だって、MYDが壊れるのはさすがにシャレになりません。
だから、cronでは、インデックスチェックだけをやりましょう。
Optimizeについてはとりあえずやめましょう、というスタンスで
Quote:
ちょっと誤解を招く書き方ですみません。
実際にそういう現象があるのであれば、DBの混雑具合によらず、Optimizeをしない、というのが一番ですね、という意味です。
だって、MYDが壊れるのはさすがにシャレになりません。
こちらこそ、書き方がまずかったですね^^;
通常のサイトであれば、Optimizeで問題ないと思います。
ただ、アクセスが集中している状態(メルマガを発行しているサイトで、メルマガ発行直後とか)でOptimizeをかける場合だけリスクがあるので、cronの設定時間に気をつける必要がある、と書けば良かったですね。
(そもそも、cron自体、深夜とかに設定する人が多いか
)
逆に、Optimizeをかけないでパフォーマンスが劣化してく方が普通にありうるので、定期的にOptimizeをかけることは全面的に賛成です。