Как сделать анализ и спроектировать сложный SQL-запрос?
"надо проектировать так как надо, а как не надо - проектировать не надо" - какой еще анализ кроме общих правил SQL? типа по индексу лучше чем без, а JOIN лучше IN
есть же хранимые процедуры - не нужно умещать все в один запрос (и да, временные таблицы - это нормально)
Как уже подметил Лентюй  - SQL изначально был ориентирован на своего рода "ботаников" - чтобы они писали "что они хотят увидеть". Остальное - дело интерпретатора-планировщика. 
И начинать надо именно с этого. В 90% случаев планировщик sql сможет построить план запроса так, что он окажется гораздо оптимальнее, чем наоптимизирует любитель.
И только в случае действительно медленного отклика - можно будет о тонких местах и погрузится в волшебный мир индексов-хэшей-лимитов памяти-хинтов и т.п. )