Я в плане sql в принципе самоучка, сейчас работаю, но понимаю, что чтобы двигаться дальше нужно как то систематизировать знания, понять что когда лучше использовать с точки зрения быстродействия, а так же почти ничего не знаю про хинты к примеру. Что посоветуете почитать, чтоб было достаточно углубленное?
Изучать SQL как сферический язык в вакууме - нет особого смысла. Особенно если ты спрашиваешь про хинты. Хинты - это опция конкретной реализации DBMS. У Оракла - свои хинты. У Microsoft - свои. И знания между ними - совершенно не переносимые. И сами хинты кажется не стандартизированы в SQL стандарте. Здесь я могу ошибаться - пускай знающие подскажут.
Вобщем если ты где-то уже работаешь и вы используете конкретную БД - то бери и читай по ней.
Я в своё время тоже искал теоретическую литературу по оптимизации SQL. Нет толком ничего. Есть Ден Тоу. Настройка SQL для профессионалов. Он пытается подогнать под оптимизацию свою теорию. Считает селективности и кардинальности для суб-запросов и рисует "облачки" - диаграммы пытаясь вывести формулу cost. Но это всё не работает. Это разбивается о практику. Ни одна практика Oracle/PG/MSQL/MySQL не подрверждает эффеткивности диаграмм Тоу. Вобщем я зря потратил время на чтение этой книги. И тебе не советую.
Есть SQL-запросы-танцоры. Я их так называю. Они скачкообразно меняют свой план при добавлении лишь одной строки в таблицу. Строка зашла. Статистика пересобралась. Формула cost подсказывает что нужно переключить с hash-join на merge-join к примеру. Но нам это не нужно. Для нас - план с хеш-джойном вполне себе хорош и работает. Почему оптимизатор ошибается - это отдельная история. По ней можно целую книгу писать. Или несколько книг. Чем ораклисты и заняты обычно. Вот здесь уставший DBA, которому надоело крутить текст языка запроса - просто вбивает хинт и план стабилизируется. Вот в этом я вижу некое оправдание хинтов. Да хинты это зло. Но в некоторых сценариях они - меньшее зло чем например менять instance properties. Бох его знает какой damage будет от глобальных изменений.
