巨大なテーブルにスピードのためにタグを保存するための最良の方法

FULLTEXTインデックスは、実際には思ったほど高速ではありません。

別のテーブルを使用してタグを保存します：

Table tags
----------
id integer PK
tag varchar(20)

Table tag_link
--------------
tag_id integer foreign key references tag(id)
content_id integer foreign key references content(id)
/* this table has a PK consisting of tag_id + content_id */

Table content
--------------
id integer PK
......

次を使用して、タグxのすべてのコンテンツを選択します：

SELECT c.* FROM tags t
INNER JOIN tag_link tl ON (t.id = tl.tag_id)
INNER JOIN content c ON (c.id = tl.content_id)
WHERE tag = 'test'
ORDER BY tl.content_id DESC /*latest content first*/
LIMIT 10;

外部キーがあるため、tag_linksのすべてのフィールドに個別にインデックスが付けられます。
`WHERE tags ='test'は1（！）レコードを選択します。
これを10,000個のタグリンクで等結合します。
そして等結合それ それぞれ1つのコンテンツレコードがあります（各tag_linkは1つのコンテンツのみを指します）。
制限が10であるため、MySQLは10個のアイテムがあるとすぐに検索を停止するため、実際には10個のtag_linksレコードのみが表示されます。
content.idは自動インクリメントされるため、数値が大きいほど、新しい記事のプロキシとして非常に高速です。

この場合、あなたは決して 等式以外のものを探す必要があり、整数キーを使用して等結合する1つのタグから始めます（可能な限り最速の結合）。

if-thens-or-butsはありませんが、これが最速の方法です。

最大で1000個のタグがあるため、どの検索も完全な目次を調べるよりもはるかに高速になることに注意してください。

最後に
CSVフィールドは非常に悪い考えであり、データベースで使用しないでください。