через каждые X записей serialnumb, может всё таки начать встречаться одинаковый resultЭто должно решаться другими способами, записывать в SQL-базу, а потом искать по ней - не самое лучшее решение. IMHO, тут больше подойдёт InMemory NonSQL-база, которая будет хранить последние X записей для каждого sessid.
WITH cte AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY `user_ip` ORDER BY `datetime` DESC
) AS `rownnum`
FROM wp_click_table
)
SELECT *
FROM cte
WHERE rownum = 1+---------+------------+
| user_ip | date |
+---------+------------+
| 1.1.1.1 | 2024-08-01 |
| 1.1.1.1 | 2024-08-02 |
| 1.1.1.2 | 2024-08-01 |
+---------+------------+#Поиск всех .zip архивов в папке со скриптом:
print("Ищу все .zip архивы в корневой папке...")
for file in os.listdir():При желании даже обезьяну можно научить писать диалпланы (хотя читать их потом будет страшно)На AEL читается несколько легче, но отлаживать сложнее. Asterisk после загрузки ael'ок переводит их в стандартный диалплан с кучей GotoIf.
line-height: 1;
1. Первичный ключ (PRIMARY KEY) - он вообще не про ускорение, а про однозначную идентификацию строки. То, что он ещё используется как индекс, это приятное дополнение. А по составным индексам всё просто. Индекс, составленный из нескольких колонок , ускоряет поиск в случае выборки по префиксу индекса. Например, для индекса (a, b, c) ускорятся запросы
и не ускорятся
2. Тут ничего конкретного не скажу, поскольку у меня highload'а нет.
3. Проблема не в самом serialnumb, а в том, как вы его получаете. Для избежания состояния гонки вам надо делать транзакцию и использовать блокировку таблицы на чтение, но тогда другие потоки будут ждать её освобождения. При этом поле serialnumb особого смысла не имеет.