[DB] Хочу убрать задержку выполнения запроса.
При выполнении соответствующих JOIN-ов (1)Честно говоря, Delphi не знаю, но вопрос, как я понял, и не требует этого знания.
У меня вопрос к автору - какие JOIN-ы имеются ввиду? В смысле о чем речь, если в запросе нет JOIN?
К тому же не похоже, чтобы такой несложный запрос для относительно маленькой таблицы (100,000 строк) выполнялся 10 секунд. Может что-то с настройками базы? Или с индексами?
К тому же не понятно, зачем создавать вьюху. Нет никакой существенной разницы между тем, будешь ли ты получать нужную информация путем запроса или используешь select из вьюхи, которая основывается на этом запросе. При вызове SELECT my_view ... все равно будет выполнен запрос, который находится в my-view. Есть материализованные вьюхи - это другое дело. Но я не уверен, поможет ли тебе это...
У меня вопрос к автору - какие JOIN-ы имеются ввиду? В смысле о чем речь, если в запросе нет JOIN?Этот запрос эквивалентен
SELECT ...
FROM Games INNER JOIN Players AS A ON FirstID=A.PlayerID INNER JOIN Players AS B ON SecondID = B.PlayerID
WHERE CustomCondition
Поэтому я и написал для удобства JOIN.
Да, и запрос исполняется не над 100 000 табличкой Games, а над Games*Players*Players. Я понимаю, что это оптимизируется, но не до 100 000 все равно.
А какой размер PLAYERS?
Когда-то видел такой косяк, типа бд-сервак составил план выполнения запроса для десятка записей и закешировал, на миллионе записей тормозило ессно.
100000 - небольшая цифра.
Что за сервер кстати?
SELECT ...А чем INNER JOIN отличается от серии AND-ов?
FROM Games INNER JOIN Players AS A ON FirstID=A.PlayerID INNER JOIN Players AS B ON SecondID = B.PlayerID
WHERE CustomCondition
Чем этот запрос лучше/хуже того, что приведено в исходном вопросе?

Настолько коряв, что план вып-я запроса не кеширует. Ну и неважно, впрочем, я сразу создал базу из 100к записей, а потом только начал слать запросы.
Почему-то у меня стойкое подозрение, что улучшить время выполнения ЭТОГО запроса не получится, по крайней мре в рамках Нексуса.
З.Ы. Таблица Games на диске весит 120 Мб, ибо там BLOB-ы. Но и при SELECT-е без блобов выполнение запроса хоть и ускоряется, но до 5 секунд, что все равно много.
А 100 000 - это для теста. Желательно, чтобы не тормозило на 3 миллионах записей.
Поставь... ну хоть MySQL, уже проблем не будет.
Если со сменой движка БД проблемы - кажися дальше только денормализация.
С точки зрения НОРМАЛЬНОГО оптимизатора запросов - тоже ничем, т.к. он должен понимать, что это одно и то же.
Мой сервер, кстати, перед выполнением запроса с INNER JOIN-ами превращает их в WHERE ... AND ..., т.е. в первый вариант.
Завтра буду пробовать на другом БД-движке, но штука в том, что они, гады, платные

SELECT GameID, FirstId, SecondId, Score, Date, ...
FROM Games
where <custom condition>
Завтра буду пробовать на другом БД-движке, но штука в том, что они, гады, платныеOracle - бесплатный
Но именно с Nexus-ом можно расчеты над ОДНОЙ таблицей перенести на клиента (т. наз. Live Request). Я с ним мало экспериментировал, но похоже, что он как раз "размазывает" эти три секунды по времени, пока юзер давит кнопку вниз

Но в случае JOIN-а ничего не катит. Сначала сервер все равно делает JOIN, на что тратит основное время.
P.S. ушел часа на два.
результат запроса нужен именно юзеру, и нужен не сразу весь, а по частямХм, я наверное не слишком правильно понял...
По логике работы приложения ты можешь сделать разбиение на страницы? если да - то вытаскиваешь общее количество записей (кстати, посмотри время выполнения) и делишь на кол-во записей на "страницу".
Или ты хочешь все равно подгрузить все записи, но как бы частями?
SELECT ... WHERE ... LIMIT 10000,1000
, но а) эта конструкция не поддерживается столь любимым Нексусом, б) подозреваю, что все равно запрос выполняется целиком.
По делу - у тебя или по какой-то причине ключи не работают, или БД жутко тупая.
Оставить комментарий
zorin29
Дано: БД с 2 таблицами: Games, Players.Players: PlayerID, Name, Country, ...
Games: GameID, FirstID, SecondID, Score, Date, ...
Юзер как правило (95%) просматривает результат следующего запроса
SELECT GameID, A.Name as First, B.Name as Second, Score, Date, ...
FROM Games, Players as A, Players as B
WHERE A.PlayerID = FirstID AND B.PlayerID = SecondID AND <custom condition>, в частности часто custom condition-а вовсе нет.
1) Query.Open;
2) DBGrid.DataSource.DataSet := Query;
При выполнении соответствующих JOIN-ов (1) SQL-сервер тормозит секунд 10 (|Games| = 100 000, индексы построены). Затем юзер просматривает результат без торможений, подкачивая при необходимости данные.
Мне не нравится торможение в 10 секунд. Как бы его убрать, т.е. "размазать" во времени?
Я надумал вариант с расслоением Games:
SELECT ... FROM ... WHERE ... AND (GameID BETWEEN 10000 AND 12000)
Такие запросы выполняются мнговенно. Но в результате из-за Custom Condition в полученном DataSet-е может оказаться слишком мало записей... Как быть?
В принципе, можно пробовать сменить архитектуру базы, сменить SQL-engine, перестать использовать SQL и т.д. - свобода довольно большая.
Решение
CREATE VIEW GamesPlayers AS
SELECT GameID, A.Name as First, B.Name as Second, Score, Date, ...
FROM Games, Players as A, Players as B
WHERE A.PlayerID = FirstID AND B.PlayerID = SecondID
SELECT * FROM GamesPlayers WHERE CustomCondition
не работает, т.к. VIEW в случае нашего SQL-сервера создается только в момент SELECT, а потом удаляется - ускорения не получаем.