デッドリンクになってしまう理由は、データ移行の際にエントリIDが変わってしまう場合があることで、特に記事のエクスポート＆インポートを行うと発生しやすいように思えます。

この時、アーカイブマッピングの設定でパスを「entry-basename.html」のような"basename"を利用するものにしていると、タイトルにアスキー文字が含まれないエントリーで、実際のエントリーとファイル名の整合性が失われてしまう場合があるようです。（※一部訂正）

なので、まずこのアーカイブマッピングは"basename"の利用を止めて、しばし検討した結果、無難に日付ベースにしました。

で、後はリンクのURLを修正しなくてはならない訳ですが、すでに1000件を越えているエントリーの中から、対象となるアンカーを含むエントリーとそのリンクURL、それから自分のエントリーが元のトラックバックURLを見つけて置き換える必要があり、これを全部手作業でやるのはかなり面倒。
（まぁだから今まで手を付けていなかったとも言う・・・^^;）

それで最初は直接SQLでDBの中をいじってしまえれば良いなと思ったものの、これらの処理を上手くSQLだけで行うには私のスキルが足りず断念。
そもそもMT自体にこのDBにアクセスするためのライブラリモジュールが用意されているのだから、それを使えば良かろうと思って、perlでCGIを組んで処理することにしました。

しかしこのモジュールの使い方って、一応ドキュメントもWeb上にあるにはあるものの、具体的に使う上では少々不親切というか情報不足。やはりMTのソースを参考にしながら少し試行錯誤を要してしまいました。

今回の変更作業のため、おそらくしばらくの間Google等の検索エンジン上での過去エントリーへのリンクはデッドになるでしょうが、どっちにしろ一部リンクはすでにデッドになってたはずだし、今後その心配が無くなるはずということで、まぁ仕方無いと思うことに。

あとついでにDBを再びMySQLに変えてみました。
あらためて見てみるとSQLiteのDBサイズが６Ｍを超えていて、ＭＴの動作も全体的にもっさりしてきた感じがあったので、試しに戻して少し様子を見てみます。

で、このDB移行はどうやるのが一番楽だろう？としばし悩みましたが、素直にＭＴのバックアップ／復元機能を利用するのが良さそうでした。
ただ、ブログIDやエントリーID等をなるべく以前と同じ値で復元したい場合、それにはテーブルの設定値をいじったり、若干の手間を掛ける必要があります。
しかしバックアップ時のデータをそっくりそのまま復元できないのは、何か気持ち悪いなぁ・・・

とまぁ、そんなこんなで結構手間暇を食ってしまいましたが、何とか目的は達せました。