|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm, лично с Вас, $20 за ответ. Реквизиты пришлю в ответ на письмо. Ответ обещаю с примером, причем повторяемым. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 16:01 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128, Ну докажите сначала, что Вы в состоянии дать адекватный пример. А то деньги возьмете и с приветом... Хотя бы принцип его работы объясните. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 16:58 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm, Попробуйте сами ответить на вопросы: Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(1)? Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(0)? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 17:27 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(1)? Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(0)? Даже если Ваша таблица в обсуждаемом примере кластерная, физических чтений не будет больше, чем общее число страниц кластерного индекса. Потому что сервер не дурак и не будет поднимать с диска страницу, если она уже есть в BP. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 22:33 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm, Я же Вам выше стоимость моих ответов озвучил. Жду в e-mail ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 23:14 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Я же Вам выше стоимость моих ответов озвучил. Жду в e-mail Так что имею все основания считать, что потрачу деньги впустую. Свои утверждения принято либо доказывать, либо ссылаться на авторитетные источники. Вы не сделали ни того, ни другого. Своим опусом 22261187 Вы ничего не доказали, а фразой ptr128 Во-вторых, видим, что параллельный план запроса в данном случае потребовал 2246 дополнительных обращений к кешу данных. То есть, при недостатке памяти дважды с диска могло читаться 0.6% страниц. Таким процентом я готов пренебречь. А было бы 6% - это уже стало бы поводом для размышлений в случае многопользовательской системы. К тому же, это вообще не ответ на обсуждаемый вопрос. В завершение, у меня для Вас, совершенно бесплатно, два подарка: 1. Для восполнения отсутствующих знаний - https://www.red-gate.com/simple-talk/sql/learn-sql-server/understanding-and-using-parallelism-in-sql-server/ и https://www.sqlservergeeks.com/lru-k-algorithm-quick-look/ 2. Скрипт, демонстрирующий физические чтения, который можете использовать для собственных экспериментов Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2021, 11:17 |
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1685210]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 315ms |
total: | 582ms |
0 / 0 |