Имя: Пароль:
1C
1С v8
Спецам SQL. Тормоза в списке документов (обычные формы, 8.2, SQL)
,
0 ptiz
 
30.10.17
10:38
Вводные данные:
Платформа 8.2.18.109, SQL 2008 standard
SQL-ю выделено 320 Гб ОЗУ, база на SSD, с проведением документов проблем нет.

Простая форма списка документов (Реализация товаров) и журнала (Реализации и возвраты).
При листании списка иногда возникают тормоза по 1.5-2 секунды на страницу (PgUp/PgDown).

Размеры таблиц:
_Document240 (шапка реализаций) - 40Гб (8 млн. документов, всё лишнее удалено)
_DocumentJournal7838 - смешные 8Гб.


Профайлер показывает большой Duration на запросе:

SELECT TOP 51
_Document240_R._Date_Time AS _A1,
_Document240_R._Number AS _A2,
_Document240_R._Fld6451 AS _A3,
_Document240_R._IDRRef AS _A4RRef,
_Document240_R._Marked AS _A5,
_Document240_R._Posted AS _A6,
_Document240_R._Fld6439RRef AS _A7RRef
FROM
_Document240 _Document240_R WITH(NOLOCK)
WHERE
_Document240_R._IDRRef > P1 AND _Document240_R._Date_Time = @P2 AND _Document240_R._Date_Time >= @P3 AND _Document240_R._Date_Time <= @P4 OR
_Document240_R._Date_Time > @P5 AND _Document240_R._Date_Time >= @P6 AND _Document240_R._Date_Time <= @P7
ORDER BY
_Document240_R._Date_Time,
_Document240_R._IDRRef

план запроса
https://yadi.sk/i/dR_S9q0z3PDPuL




Аналогичная картина с журналом документов (реализации и возвраты вместе):

SELECT TOP 48
_DocumentJournal7838_R._Date_Time AS _A1,
_DocumentJournal7838_R._Number AS _A2,
_DocumentJournal7838_R._Fld7841 AS _A3,
_DocumentJournal7838_R._DocumentTRef AS _A4TRef,
_DocumentJournal7838_R._DocumentRRef AS _A4RRef,
_DocumentJournal7838_R._Marked AS _A5,
_DocumentJournal7838_R._Posted AS _A6
FROM
_DocumentJournal7838 _DocumentJournal7838_R WITH(NOLOCK)
WHERE
_DocumentJournal7838_R._DocumentRRef > P1 AND _DocumentJournal7838_R._Date_Time = @P2 AND _DocumentJournal7838_R._DocumentTRef = @P3 AND _DocumentJournal7838_R._Date_Time >= @P4 AND _DocumentJournal7838_R._Date_Time <= @P5 OR
_DocumentJournal7838_R._DocumentTRef > @P6 AND _DocumentJournal7838_R._Date_Time = @P7 AND _DocumentJournal7838_R._Date_Time >= @P8 AND _DocumentJournal7838_R._Date_Time <= @P9 OR
_DocumentJournal7838_R._Date_Time > P10 AND _DocumentJournal7838_R._Date_Time >= P11 AND _DocumentJournal7838_R._Date_Time <= P12
ORDER BY
_DocumentJournal7838_R._Date_Time,
_DocumentJournal7838_R._DocumentTRef,
_DocumentJournal7838_R._DocumentRRef

план запроса
https://yadi.sk/i/hvoQh2RU3PDPrH



Что можно подкрутить в SQL, чтоб он листал быстрее?
48 ptiz
 
30.10.17
16:52
(39) Я оставил самый минимум: номер и дату. Сделал покрывающий индекс (через "помощника настройки ядра СУБД" - подсунул ему этот запрос). Один черт - индекс скан по этому индексу, скорость такая же.
https://yadi.sk/i/T-kBh5s73PENoR
49 ptiz
 
30.10.17
16:53
Видимо, sql не может переварить запрос с такой кучей условий на даты, который генерит список документов.
50 vde69
 
30.10.17
16:53
(48) так оптимизатор заработает по новому индексу только после сброса статистики
51 rphosts
 
30.10.17
16:56
(46) не приятгивайте за уши методологию обслуживания БД с вмешательством в структуру Б
52 rphosts
 
30.10.17
16:56
Б= ИБ
53 rphosts
 
30.10.17
16:58
(48) 1802 это Duration?
54 rphosts
 
30.10.17
16:59
(50) и чистки процедурного кэша... и да, дефрагментацию давно выполняли?
55 alkorolev
 
30.10.17
17:06
(45) мануалы написаны по сопровождению СУБД, а не об изменении физической сущности базы НЕ средствами эсочки. Грубо говоря, если вы покупаете УТ, вставляете триггер, где при инсёрте нового элемента номенклатуры реиндексируете всю базу, а потом жалуетесь в компанию 1С, что их программа тормозит и г*вно, то 1С в свою очередь может вас послать (и обязательно пошлёт).
56 Alex_MA
 
30.10.17
17:12
(48)Видимо из статистических данных MSSQL решил что так будет оптимальнее...(На выполнение запроса может повлиять и статистика)
57 alkorolev
 
30.10.17
17:13
(0) рлс исключил? под полными правами тож торомзит? создай обработку, сделай в ней форму списка журнала документов. Что за привычка сразу в профайлер лезть?
58 breezee
 
30.10.17
17:15
(17) Попробуйте перевести этот список на управляемые. Планы обслуживания на скуле смотрели?
59 alkorolev
 
30.10.17
17:15
SELECT TOP 51
60 alkorolev
 
30.10.17
17:15
это динамический запрос что ль? что вообще за программа?
61 rphosts
 
30.10.17
17:17
(57) в профайлере запрос с учетом рлс, тебе ли этого не знать
62 rphosts
 
30.10.17
17:17
(60) видимо запрос динамического списка
63 Ёпрст
 
30.10.17
17:18
а в результате окажется, что на форме есть какой либо текстовый реквизит, который получает значение из текущей строки списка, таща на клиента весь объект целиком
64 vde69
 
30.10.17
17:21
(62) (63) как я понял у автора ОБЫЧНЫЕ формы
65 vde69
 
30.10.17
17:22
(57) рельсы тут нет, это видно по запросу... рельса ВСЕГДА выполняется внутри ХП...
66 craxx
 
30.10.17
17:23
(0)RLS?
67 ptiz
 
30.10.17
17:34
(53) Да, он.
(63) Причем тут форма, если есть конкретный запрос SQL с duration 1800?
(66) С RLS запрос выглядел бы совсем по-другому.
68 vde69
 
30.10.17
17:39
(67) кстати вопрос:

SQL на виртуалке?
69 Ёпрст
 
30.10.17
17:39
(67) 1800- это же 1.8мс, долго ?
70 rphosts
 
30.10.17
17:43
(69) Duration в миллисекундах, это 1,8 сек
71 Ёпрст
 
30.10.17
17:44
(70) разве ? А не в микросекундах ?
72 Ёпрст
 
30.10.17
17:44
не помню ужо
73 ptiz
 
30.10.17
17:44
(68) Нет конечно.
74 rphosts
 
30.10.17
17:44
(67) можно текстовый план запроса?
75 mistеr
 
30.10.17
17:49
Не вижу плана почему-то (что-то с Яндексом). Так что там с индексом, поясните кто вкурил? Индекс по дате+ссылке должен быть стандартный у всех доков, предназначен именно для списков. Чтобы при запросе дин. списка скуль пошел не по этому индексу, это нужно очень постараться.

Может сортировка в списке не та? Может нужно сделать ТИИ с реиндексацией?
76 vde69
 
30.10.17
17:50
в свойствах базы смотри все параметры типа

"Автоматическое обновление статистики" и прочее связанные со статистикой...

зы
мне кажется, что дело именно в статистике
77 rphosts
 
30.10.17
17:54
(70) Сервер сообщает о длительности события в микросекундах (10^-6 с), а о количестве времени, затраченного ЦП на событие, в миллисекундах (10^-3 с). В Приложение SQL Server Profiler графический пользовательский интерфейс по умолчанию отображает столбец Продолжительность в миллисекундах, но, когда данные трассировки сохраняются в файле или таблице базы данных, значение столбца Продолжительность записывается в микросекундах.

https://docs.microsoft.com/ru-ru/sql/tools/sql-server-profiler/view-and-analyze-traces-with-sql-server-profiler
78 ptiz
 
03.11.17
15:27
(74) Наконец снова добрался до базы.
Вот план запроса из технологического журнала:
0, 1, 47, 0, 4.7E-006, 76, 0.00733, 1,   |--Top(TOP EXPRESSION:((47)))
0, 1, 47, 202, 6.31, 76, 0.0069, 1,        |--Clustered Index Scan(OBJECT:([test_copy].[dbo].[_DocumentJournal7838].[_Docume7838_ByDocDate_TR] AS [_DocumentJournal7838_R]),  WHERE:([test_copy].[dbo].[_DocumentJournal7838].[_DocumentRRef] as [_DocumentJournal7838_R].[_DocumentRRef]>[@P1] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]=[@P2] AND [test_copy].[dbo].[_DocumentJournal7838].[_DocumentTRef] as [_DocumentJournal7838_R].[_DocumentTRef]=[@P3] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]>=[@P4] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]<=[@P5] OR [test_copy].[dbo].[_DocumentJournal7838].[_DocumentTRef] as [_DocumentJournal7838_R].[_DocumentTRef]>[@P6] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]=[@P7] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]>=[@P8] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]<=[@P9] OR [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]>[@P10] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]>=[@P11] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]<=[@P12]) ORDERED FORWARD)

Т.е. Clustered Index Scan - и всё. И это медленно.
79 rphosts
 
03.11.17
17:26
(78) время адекватное запросу... сделайте новый журнал без единой строчки кода, откройте под пользователем с полными правами
80 mistеr
 
03.11.17
18:03
(78) Clustered Index Scan и должен быть. План нормальный. Странно, что медленно. статистику по I/O бы глянуть...

Может все-таки переиндексировать? Кто в курсе, при ТИИ кластерные индексы пересоздаются?
81 ptiz
 
03.11.17
19:42
(80) Переиндексировал, и через 1С реструктуризировал журнал (когда графы меняешь).
Я бы согласился, что нормально, но когда снизу вверх листаешь - всё намного быстрее :(
82 ptiz
 
03.11.17
19:43
(79) А какая графа тут время отображает? И в каких единицах?
83 mistеr
 
03.11.17
19:46
(81) Со стороны 1С все норм, проблема в скуле имхо. Или в конкретной базе.
84 mistеr
 
03.11.17
19:47
(81) Раз уж тронул журнал, попробуй из состава доки убрать, чтоб он очистился. А потом вернуть.
85 Borteg
 
03.11.17
22:20
(0) в обеих списках в запросе нету поля description, при выводе на каждую строку идут обращения к sql?
86 Borteg
 
03.11.17
22:22
(78) при --Top(TOP EXPRESSION:((47)))  всегда будет скан это самое быстро что можно сделать
87 Borteg
 
03.11.17
22:46
(0) скорей всего проблема в ссылочных типах и их выводе на экран. надо выводить представление от ссылки, а ссылки скрывать видимость(если нужны отборы)
88 Cyberhawk
 
03.11.17
23:17
Думаю, после праздников проблема сама собою рассосется
89 youalex
 
03.11.17
23:18
(78) какое-то дикое условие
попробовал на своем журнале (отбор по периоду установлен, видимость ссылочных колонок отключена):

WHERE ((T1._Date_Time >= P1) AND (T1._Date_Time <= @P2)) AND T1._Date_Time = @P3 AND T1._DocumentTRef = @P4 AND T1._DocumentRRef > @P5

Откуда у тебя остальные условия берутся, вообще непонятно.

Пробуй, как уже сказали, ЖурналСписок в новой, пустой форме. Интересно, дин. список какой запрос сформирует.
На крайний, журнал всегда можно заэмулировать через РС.
90 Sasha_H
 
03.11.17
23:23
91 Sasha_H
 
03.11.17
23:25
(0)
Полагаю, что у автора все регламенты, статистика/индексы обновляются.

Попробую в настройках списка вообще установить полные стандартные настройки. Вообще снять сортировку любого рода.
92 Sasha_H
 
03.11.17
23:26
очень помагает еще использование последней платформы
93 Sasha_H
 
03.11.17
23:28
советую использовать 8.3
94 mistеr
 
03.11.17
23:29
(89) Там не один запрос идет, а несколько. Ты полистай туда-сюда.
95 Sasha_H
 
03.11.17
23:34
Я может где-то пропустил это же УФ или обычная форма?
96 youalex
 
03.11.17
23:35
(94) Ну да. Параметры меняются.
97 mistеr
 
03.11.17
23:36
(90) >проблемы в операторе ORDER BY,  который платформа сама старательно добавляет, и неважно, что сортировка вообще пользователем не указана
>Осталось только ждать и надеяться, что 1С все-таки согласится исправить такое поведение ДС

Вывод автор статьи сделал неверный. Без ORDER BY не будет никакого ДС. Важно, чтобы этот ORDER BY попадал в индекс и не требовал доп. сортировки. В остальном статья норм.
98 mistеr
 
03.11.17
23:38
(96) Не только параметры, но и сами запросы. Просто задумайся над условием "_Date_Time = @P3"
99 Sasha_H
 
03.11.17
23:38
(97) спорно. и можем много спорить. Ест-но что без сортировки не будет ДС. Но как ведомо сортировка отжирает весомый процент.
100 Sasha_H
 
03.11.17
23:40
(97) ну вот и тебе ответ обрати внимание на покрытия своих индексов, на что идет трудоемкость в плане запроса. Поиск ключа.
101 Sasha_H
 
03.11.17
23:44
а поиск ключа если я не ошибаюсь происходит в случае, когда выводятся колонки которые вне индекса.
102 Sasha_H
 
03.11.17
23:52
В этом запросе я непонял зачем дважды выводиться одна и таже ссылка?

_DocumentJournal7838_R._DocumentTRef AS _A4TRef,
_DocumentJournal7838_R._DocumentRRef AS _A4RRef,

И вот:
ORDER BY
_DocumentJournal7838_R._Date_Time,
_DocumentJournal7838_R._DocumentTRef,
_DocumentJournal7838_R._DocumentRRef
103 Sasha_H
 
03.11.17
23:53
у вас, что там соединения с ТЧ какие-то?
104 mistеr
 
03.11.17
23:56
(100) "Поиск ключа" это key lookup что ли? Некорректный перевод, это "поиск по ключу".

У автора статьи ситуация другая. У него запрос к таблице документа, там индекс по дате некластерный, а данные тянутся из кластерного, из-за этого большая трудоемкость. Тут же индекс на журнале кластерный, поэтому никаких key lookup, ничего лишнего, Index scan + top. Но почему-то медленно. Нужно смотреть статистику.
105 mistеr
 
03.11.17
23:57
(102) Это тип + ссылка (TRef + RRef)
106 Sasha_H
 
03.11.17
23:57
(78) Т.е. Clustered Index Scan - и всё. И это медленно.

Скан это плохо. Это значит, что он проходит таблицу сканируя. А вдолжен быть SEEK

Явно говорит о том, что нет покрытия полей в индексе
107 Sasha_H
 
04.11.17
00:02
108 Sasha_H
 
04.11.17
00:03
Ссылка - кластерный индекс всегда
109 Sasha_H
 
04.11.17
00:03
[ОРРХ | ОРНР1 +] Дата + Ссылка
110 Sasha_H
 
04.11.17
00:04
ДС и делает сортировку по дати и ссылке поскольку полагается, что это кластерный индекс
111 Borteg
 
04.11.17
00:06
(106) в выборе первых записей будет всегда скан, и он не сканирует всю таблицу он выбирает только первые 50 записей
112 Sasha_H
 
04.11.17
00:08
(111) в данном случае согласен поскольку испльзуется ключевое ТОР
113 youalex
 
04.11.17
00:08
(98) >>Просто задумайся над условием "_Date_Time = @P3"

Задумывался))
Сейчас вижу, что два запроса выполняется, один с "AND T3._Date_Time > @P3" (если листать вверх, то < @P3, что логично).
Второй уже, видимо, строится по результатам первого, с "_Date_Time = @P3 AND T2._DocumentTRef < @P4"

В обоих случаях - Index Seek,  ничего похожего на монструозное условие ТС нет.
114 Sasha_H
 
04.11.17
00:10
(113) ввобще-то ДС при первом открытии имеет один вид запроса. А поотм другой. Это сделано для того-чтобы поймать курсор.

Но автору я бы настоятельно рекомендовал обновить платформу.
115 Sasha_H
 
04.11.17
00:11
(0) Автор почитай что сделали в платформе 8.3.10 там большой уклон пошол на оптимизацию и ускорения работы и очень много работы на ДС припало.
116 Borteg
 
04.11.17
00:16
кстати это микросекунды же, у меня в профайлере в микросекундах указывается. 1400 это вообще мизер тогда и проблема не в запросах.
117 Borteg
 
04.11.17
00:17
ну и нету здесь decription как тогда ссылочной тип на форму попадает? в sql должно быть много доп запросов на вывод строк. этого не видно в том что дали.
118 Sasha_H
 
04.11.17
00:17
Забили - автора давно нет тут!
119 mistеr
 
04.11.17
00:30
(113) Показывай запросы и планы. Только текстом, пожалуйста. На pastebin очень удобно. И версии платформы и скуля.
120 youalex
 
04.11.17
00:37
(116) не факт, это настраиваемый параметр (милли или микро)
121 youalex
 
04.11.17
00:38
(119) Зачем? У меня все нормально))
122 mistеr
 
04.11.17
00:48
(121) Интересно сравнить с ТС
123 youalex
 
04.11.17
01:29
124 youalex
 
04.11.17
01:33
(123) +
8.2.19.106
Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64)
125 mistеr
 
04.11.17
02:01
(123) Сейчас уточнил в BOL. INDEX SCAN это полный просмотр индекса, а INDEX SEEK - поиск по ключу. (Я привык к оракловой терминологии, где scan обозначает и то и другое.)

https://technet.microsoft.com/en-us/library/ms175184(v=sql.105).aspx
https://technet.microsoft.com/en-us/library/ms190400(v=sql.105).aspx

Так что почти все стало ясно у ТС. Скуль выбирает scan, скорее всего из-за двух OR в условии. Вместо того, чтобы сделать три раза seek и сортировку. Может, и кривая статистика вносит свой вклад.

Откуда там взялись эти OR, остается интересным.
126 mexanik_96
 
04.11.17
06:41
про покрывающий индекс уже было?
127 mexanik_96
 
04.11.17
06:41
вообще у автора ожидание page latch, поднятие страниц с диска есть?
128 mexanik_96
 
04.11.17
06:44
(125) ну да с чего бы? он скан делает потому что индекса покрывающего нет по предикату
129 rphosts
 
04.11.17
07:45
(78) всё-же сделайте как написано в (79) и ещё кроме того, попробуйте  кликнуть по колонке Дата что-бы отсортировались документы по дате и посмотрите что после этого будет со скоростью.
130 Borteg
 
04.11.17
09:40
(125) он не сканирует всю таблицы, у него есть TOP в запросе. Он просто отбирает 50 записей сканом  и все...
131 H A D G E H O G s
 
04.11.17
09:48
(130) Ага. Это так, если нет условия в запросе.
132 Borteg
 
04.11.17
09:53
(131) это всегда так. В первом запросе вложенные циклы выполнялись только 51 раз, а не скан с поиском ключа и  потом выбор 51 строки. В планах нету  sort. Значит он попал в индекс по сортировки.
133 ptiz
 
04.11.17
10:30
(93) Это не так просто. Пока 8.2 в режиме совместимости 8.1. Переходить на 8.3 (даже только смена платформы) - к тому времени или ишак, или эмир :)
(95) Всё обычное (см.заголовок).
Уточню: при листании последнего месяца - по 10 страниц в секунду пролетает.
При листании января - на каждый PgDown уходит больше секунды.

(129) После праздников попробую сортировать туда-сюда. А права и так полные.
134 Злопчинский
 
04.11.17
10:53
Наблюдаю.
Особенно тех кто заявляет "вы не умеете её готовить"
Посмотрим...
Интересно.
135 mistеr
 
04.11.17
11:06
(128) Все поля из предикатов есть в индексе. Индекс кластерный, так что все остальное там тоже есть, по определению.

(130) >Он просто отбирает 50 записей сканом  и все...
А какие именно 50 записей, из какого места? Ты физическую структуру индекса немного представляешь себе?
136 rphosts
 
04.11.17
13:15
(133)  главеое сделай пустую форму чтоб ни строчки кода
137 Sasha_H
 
04.11.17
14:27
(0) Какой период в списке? Попробуйте установить минимальный период например Текущий день.

Возможно у вас в спике используется такие понятия как ПриАктивизацииЯчейки, приПолученииДанных и т.д. Есть ли в списке вообще другие обработчики, этот список Чист без разных обработчиков?
138 Sasha_H
 
04.11.17
14:31
сделать ТиИ - одна из рекомендаций ИТС. Но мне не нравиться, что конфа вообще в совместимости 8.1
139 Sasha_H
 
04.11.17
14:34
(133) Я думаю многие оптимизаторы со мною согласятся - вот все работало прекрасно и замечательно и бах...

Это все проблемы так начинаются. И тут проблематика в данном случае если у Вас вообще "Чистый список" без лишнего кода при обработке данных например на лету. И Вы начинаете вот так висеть. Индексы перестроены, статистика не помогает, ТиИ тоже, диски крутые и все точка.

В данном контексте у вас 8.2 да еще на совместимости с 8.1 тоже не айс. Я уже молчу о взаимоблокировках.
140 ptiz
 
04.11.17
18:06
(136) В форме закомментирован весь код.
Вот видео, где листаю страницами: видно, что тормозит январь, а октябрь - летает.
https://youtu.be/iju8hUr95FY
(139) Про взаимоблокировки я бы поспорил. Правильные управляемые блокировки уже в 8.1 рулят и педалят в самописках.
"вот все работало прекрасно и замечательно и бах... " - такого не было. Просто количество документов перешло в качество.
141 youalex
 
04.11.17
19:58
(140) Попробуй, ради интереса, еще сделать обработку, в ней УФ, в УФ - дин. список с этим журналом. Какой там запрос будет генериться.
Вроде бы УФ открывается даже в режиме совместимости 81, если не внешняя.
142 Злопчинский
 
04.11.17
20:38
Продолжаю с интересом наблюдать. Где же все специалисты, которые умеют её готовить?
143 ptiz
 
07.11.17
12:17
Как и ожидалось, дело оказалось в платформе 1С.
Убрал режим совместимости 8.1 (платформу не менял, та же 8.2, обычные формы): сразу поменялся текст запроса к СУБД, и план запроса превратился в Clustered Index Seek.

Запрос стал такой:
SELECT TOP 43
T2._Date_Time,
T2._Fld7841,
T2._DocumentTRef,
T2._DocumentRRef,
T2._Marked,
T2._Posted
FROM _DocumentJournal7838 T2 WITH(NOLOCK)
WHERE ((T2._Date_Time >= P1) AND (T2._Date_Time <= @P2)) AND T2._Date_Time = @P3 AND T2._DocumentTRef > @P4
ORDER BY (T2._Date_Time) ASC, (T2._DocumentTRef) ASC, (T2._DocumentRRef) ASC
OPTION (FAST 1)
144 ptiz
 
07.11.17
12:30
Кстати, модный "динамический список" в управляемой форме - тормоз страшный. До "ЖурналДокументовСписок" - ему не дотянуться.
145 Sasha_H
 
14.11.17
21:10
(144) Кстати иметь овно конфигурацию в режиме совместимости 8.1 при этом платформа даже не 8.3 умозаключение МЕЛКОЕ!
146 H A D G E H O G s
 
14.11.17
21:12
(144) Модный динамический список иногда незаменим.
147 g00d
 
15.11.17
01:57
(144) идея дин.списка что вы возвращаете только то что вам нужно, начните с того что - уберите лищние колонки