Mam taki problem... Stworzyłem stronkę, gdzie można dodawać recenzje i wystawiać komentarze. Obecnie recenzje nie są weryfikowane i od razu pojawiają się na stronie. I uświadomiłem sobie, że gdy strona się rozrośnie, to może być problem ze spamem. Dlatego warto chyba byłoby wprowadzić w przyszłości moderację przed publikacją. Zastanawiam się, jak to rozwiązać, aby strona działała maksymalnie szybko? Kiedyś dla tabeli bazy danych (np. "review") wprowadzałem atrybut (np. "review_active") typu logicznego. Potem wyświetlałem na stronie tylko dane aktywne (po moderacji). Problem jest taki, że działało to wolno, bo większość wpisów była aktywna i index (key) niewiele dawał. Zapytania na tabeli z 300k wpisów potrafiły wykonywać się kilkanaście sekund. To zdecydowanie zbyt długo...

Jak najprościej rozwiązać ten problem? Pomyślałem, że można byłoby dodawać nowe wpisy do innej tabeli. Gdy moderator zatwierdzi wpis, to można byłoby dodać go w docelowej tebeli ("review") i usunąć z tej tymaczasowej... Ma to sens bądź można to zrobić lepiej?

Jeśli w tabeli będzie więcej rekordów aktywnych, niż nieaktywnych, to indeks i nie pomoże (przy warunku "aktywny=1").
Nie jest potrzebna odrębna tabela.
Jeśli Twoje zapytanie wykonywało się wolno, to problemem jest najpewniej inny warunek w zapytaniu (być może na polu bez indeksu), a nie liczba rekordów.

Flaga "active" czy "moderated" to dobry kierunek. No i nie musisz nakładać indexu na tą kolumnę, bo to bez sensu.
I tak jak @trueblue pisał - problem w poprzednim projekcie wynikał z czegoś innego niż samej flagi.

W starym projekcie miałem sortowanie po dacie dodania wpisu, a nie po indeksie głównym (id). Miałem wprawdzie nałożony indeks na datę, ale przy tym łączyłem wiele tabel i sprawdzałem aktywność. Wolno to działało... W nowym projekcie unikałem łączenia tabel, gdzie się tylko dało. Ma to znaczenie?

Na pola złączeń też powinny być założone indeksy. Z tego co pamiętam na poziomie mechanizmu bazy danych i tak INNER JOIN jest zmieniany w WHERE.

No właśnie... Ja ustawiałem indeksy dla kolumn, które używałem w WHERE lub ORDER BY. Ale przy PRIMARY KEY, UNIQUE KEY, FOREIGN KEY już nie stosowałem ponownie samego KEY (indeksu), bo wydawało mi się, że się będą niepotrzebnie dublować...

Jak to z tym jest? Klucz główny, unikalny i obcy wymagają dodatkowej deklaracji indeksu zwykłego (KEY)?

Nie wymagają. Choć jeśli np. klucz jest założony na dwóch lub więcej polach jednocześnie, to być może trzeba będzie założyć odrębne klucze na tych polach.
Możemy gdybać. Bez przykładu trudno powiedzieć dlaczego Twoje zapytania wykonywało się tak długo.

Dzięki za pomoc. Najprościej chyba zmodyfikować zapytania SQL, aby problem przestał występować. Na forum to faktycznie wróżenie z fusów.