Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Производительность сортировки.
|
|||
|---|---|---|---|
|
#18+
Торможу, Param1->Value ведет в таблицу BAG.Params1, но все-таки индекс по Value не используется. Или его там нет, или с ним что-то не так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2009, 11:59 |
|
||
|
Производительность сортировки.
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Торможу, Param1->Value ведет в таблицу BAG.Params1, но все-таки индекс по Value не используется. Или его там нет, или с ним что-то не так.Я, конечно, могу заблуждаться, но, как мне кажется, это не должно иметь особого значения в данном случае, поскольку выборка данного значения осуществляется из небольшого справочника в самом начале, и, согласно плану, на дальнейшем исполнении запроса никак не сказывается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2009, 13:06 |
|
||
|
Производительность сортировки.
|
|||
|---|---|---|---|
|
#18+
Ну мне же неизвестно было, какой размер у таблицы BAG.Params1 А сколько строк в результате выборки должно появиться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2009, 08:35 |
|
||
|
Производительность сортировки.
|
|||
|---|---|---|---|
|
#18+
Hisbreht Victor, Caché 2009.1.FT1 На моей машине (Intel Core2 Duo, 2Гб) выборка с отображением ID всех 2000000 записей на C# занимает 28 секунд: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. И планы запросов на моих данных не такие как у Вас. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2009, 15:13 |
|
||
|
Производительность сортировки.
|
|||
|---|---|---|---|
|
#18+
krvsaMaWrперед выдачей даже одного значения необходимо выполнить полную выборку (по всем данным). Эт того-то и задержка. Даже если сортирока по возрастанию и имеет надежду ускорения с "подключением" некоего индекса... То сортировка по убыванию теряет всякую надежду на ускорение. Как вариант ускоряться в другом направлении. Вплоть до прямого доступа... Наличие индексов на полях, участвующих в сортировке, приводит к ускорению запроса в независимости от направления сортировки. Планы запросов приведены для версии 5.0.21: Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2009, 15:57 |
|
||
|
Производительность сортировки.
|
|||
|---|---|---|---|
|
#18+
>Наличие индексов на полях, участвующих в сортировке, приводит к ускорению запроса Мой опыт говорит об обратном. По крайней мере в каше 5.2 в запрос select * from table where field1=value1 order by field2 выполняется намного дольше при наличии индекса по field2, потому что независимо от селективности почему-то используется индекс по field2 При том, что select * from table where field1=value1 выдается быстро и количество записей небольшое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2009, 05:28 |
|
||
|
Производительность сортировки.
|
|||
|---|---|---|---|
|
#18+
Блок А.Н., В версии 5.2 - вполне возможно. Это кандидат на запрос о проблеме в WRC. В версиях 2008.2.1.902, 2009.1.FT1 планы запросов следующие: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2009, 09:13 |
|
||
|
|

start [/forum/topic.php?fid=39&gotonew=1&tid=1558552]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
89ms |
get topic data: |
8ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 373ms |

| 0 / 0 |
