我有一個MySQL的問題MySQL問題：列上的索引！
我在一兩個表（帖和作者）一對多的關係（因爲每個職位由個人觀點，作者可以寫多個職位）。
因此，這裏的表：
Authors:
id:BIGINT, name:VARCHAR(255)
Posts:
id:BIGINT, author_id:BIGINT, body:TEXT
我有70萬個崗位60000個作家。
如果讓我選擇一個作家（如AUTHOR_ID = 45），我想他寫的一個隨機的文章，我寫：
SELECT * FROM Posts WHERE author_id = 45 ORDER BY RAND() LIMIT 1;
我知道這是正確的，但是當我4000同時人們在網上花費大約6秒..
也許索引在Posts表中的author_id列會加速東西？
謝謝大家！ :)
是的，你一定要添加索引。
CREATE INDEX Post_author_id ON Posts(author_id);
進一步證明，運行
EXPLAIN SELECT * FROM Posts WHERE author_id = 45 ORDER BY RAND() LIMIT 1;
索引應反映您最常用的WHERE子句場景。
在這種特殊情況下，創建索引，然後將查詢改成這樣：
SELECT id,author_id,body
FROM Posts
WHERE author_id = 45
ORDER BY RAND()
LIMIT 1;
這將防止架構查找搜索之前，從而提高性能。
對於高頻查詢，SELECT *是邪惡的。
如果你還沒有和指數AUTHOR_ID，一定會把它一個。此外，我不確定ORDER BY RAND（）不對性能缺陷負責。嘗試添加索引，它應該已經有了顯着的提高。
特別是在您讀取數據的情況比您更新數據的情況更多時，請在設置索引時大方。任何你曾經在where子句中都應該被索引。
Author_id上的[可能聚簇]索引將明確提供幫助。
ORDER BY RAND（）似乎還有一個額外的風險因素。從本質上講，這個子句會導致SQL動態地爲每一行分配一個隨機數（對於一個給定的Author_id），並對它們進行排序。這可能會成爲一個瓶頸，因爲一些多產的作者開始擁有數十萬個帖子。
如果author_id是外鍵，那麼它不需要創建索引。它有內置索引。
是你的語法添加一個不同於任何方式的索引？ ALTER TABLE帖子ADD INDEX（author_id） – checcco
是的，這些語法是不同的。 :-)'ALTER TABLE'在數據庫之間不是很便攜，而'CREATE INDEX'非常便攜。我討厭SQL，所以只能記住便攜式的東西。 –