alexalexes

1. Выбрать из базы запись по известному user_id.
2. Если получили запись, то выполнить обновление атрибута записи win = win + 1 где user_id этой записи равен известному user_id (то же самое в случае проигрыша loss = loss + 1).
3. Если не получили запись, то делаете вставку записи пользователя, с win = 0, loss = 0 (с 1 в нужной ситуации).

У MySQL для сортировки кириллицы нет специфичных рекомендаций к order by.
Только, если вы не захотите применить естественную сортировку (от кодировки не зависит), то в MySQL нет для этого функций, есть некоторое подобие решения проблемы:

select '10' Name union
select '1' Name union
select '20' Name union
select '2' Name
order by length(Name), Name

Если нужно ограничить выборку по вычисляемой колонке case, а разбирать смысл ее лень (или вы в процессе отладки это делаете), то нужно взять этот кейс, перетащить в where и проверить на is not null. Все, что в условия кейса попадает - будет строковым значением (нужно глазками посмотреть, чтобы в кейсе не было исходов с null), а все что не попадает в его условия - обратится в null (если явно не прописан else).

SELECT id,
CASE
  WHEN price > 10000 AND price < 11000 THEN 'Economy'
  WHEN price >= 20000 AND price <= 30000 THEN 'PremiumEconomy'
  WHEN price > 100000 THEN 'Business'
END as service_class, price
FROM tickets
where CASE
  WHEN price > 10000 AND price < 11000 THEN 'Economy'
  WHEN price >= 20000 AND price <= 30000 THEN 'PremiumEconomy'
  WHEN price > 100000 THEN 'Business'
END is not null

А если делать по уму, конечно, кейс оставлять в where - это крайняя мера. Его быть не должно, это ухудшит показатели плана выполнения запроса (не всегда). Нужно вытаскивать булеву конструкцию, желательно, логически упрощенную.

SELECT id,
CASE
  WHEN price > 10000 AND price < 11000 THEN 'Economy'
  WHEN price >= 20000 AND price <= 30000 THEN 'PremiumEconomy'
  WHEN price > 100000 THEN 'Business'
END as service_class, price
FROM tickets
where (price > 10000 AND price < 11000) --  'Economy'
   or (price >= 20000 AND price <= 30000) --  'PremiumEconomy'
   or (price > 100000) -- 'Business'

PS: Конечно, странные у вас кусочные интервалы между классами обслуживания. Скажем, показатель в 12000 выпадет из любого класса. Обычно, их делают перекрывающими диапазонами. Ну, да ладно, тем интересней для вас разбирать запрос.

О порядке добавления записей не нужно заботиться.
У СУБД нет задачи хранить записи в строгом порядке, ваша задача понять, удовлетворит ли вас результат сортировки, если при выборке задать сортировку по darg-w:

select *
  from verbs
order by darg-w

Если хотите получать список в порядке добавления, то логично сортировать по id:

select *
  from verbs
order by id

Если хотите особую сортировку, которая не подчиняется ни id, ни естественному весу строк, то можете ввести новую колонку и следить за позиционированием строк при выборки сами, или по каким-то другим правилам вычислять позицию:

select *
  from verbs
order by position -- дополнительное поле, в которое будете сами или программно вбивать порядок сортировки

Или запрос может выдергивать сам определенные строки, давая им высший приоритет (можно написать любое правило, что требует бизнес логика, или что в голову сбредет):

select *
  from verbs
order by case when id = 100 then 0 else 1 end -- даем записи id=100 наивысший приоритет, в любом состоянии списка она будет на 1 месте!
        , id -- остальные записи отсортируются в порядке добавления

PS: Важно, чтобы поля, которые применяются в сортировке, были проиндексированы (в схеме СУБД были созданы индексы по данным полям и они своевременно пересчитаны).

С помощью функции json_to_recordset проводите нормализацию таблиц, чтобы на выходе pair получилась вот такая псевдотаблица-выборка:
pair
id_group, name
1, "ананас",
1, "апельсины",
2, "ананас",
2, "арбуз"
...
Дальше тоже самое делаете с order_list.
Ну, а дальше все приведено в 3-ю нормальную форму, можно, наконец, использовать SQL-ные сравнения/соединения этих псевдовыборок и высчитывать кол-ва того-сего.
PS: Такое решение годится как разовое для получения результата, например, если вам нужно срочно сделать нестандартный отчет для руководства, а структура таблиц спроектирована из рук вон плохо.
Нужно изначально планировать структуру базы так (приводить к 3-й нормальной форме), чтобы не прибегать к декомпозиции полей с помощью функций JSON, если компоненты внутри JSON будут использоваться для соединения между таблицами.

FROM views v JOIN memes m JOIN comments c
Вы конечно, не указали, в какой СУБД пишете, но странно видеть JOIN без ON или USING.
Если это эквивалент синтаксиса с USING, то вы увидите статистику, если по пользователю есть И просмотры, И мемы, И комментарии. Если в одной из таблиц не будет записей, то пользователь вывалится из статистики.
Если это эквивалент:
FROM views v, memes m, comments c
То такое декартово произведение таблиц с использованием distinct будет не производительно.
Рационально вам написать такое:

SELECT (select COUNT(v.id) from views v where v.user_id = u.user_id )      AS просмотры,
       (select COUNT(DISTINCT v.meme_id) from views v where v.user_id = u.user_id) AS [уникальные просмотры],
       (select COUNT(m.id) from memes m where m.user_id = u.user_id)      AS [выложено мемов],
       (select COUNT(c.id) from comments c where c.user_id = u.user_id)      AS [написано комментариев]
  FROM users u -- лучше связаться с таблицей users
 WHERE u.user_id = 1

Тогда каждый подзапрос будет работать по своей агрегации (да, если по какой-то таблице не будет записей, то вы увидите по ней ноль, а не пустую строчку по всем параметрам), дистинктовать вам нужно только по параметру уникальные просмотры - но его использование не связано с размножением записей при объединении таблиц, так что он посчитает его достаточно быстро.
PS: Если вы не забыли создать индексы для v.user_id, v.meme_id, m.user_id, c.user_id, то должно все летать на космической скорости.

1. Вычисляете агрегированную выборку - подзапрос A.
2. Сортируете выборку в том порядке, как собираетесь нумеровать - подзарос B.
3. Нумеруете строки доступной функцией в конкретной СУБД (в Oracle это rownum, в остальных средах есть row_number, в MySQL 5 версии нужно делать костыль из пользовательской переменной @ и if-a).

select rownum, B.*
from (select A.*
            from (SELECT v.user_id,
                  u.nickname,
                 COUNT(DISTINCT v.meme_id) as meme_count
                FROM views as v
                   join  users u on u.id = v.user_id
               GROUP BY v.user_id, u.nickname) A
        order by A.meme_count desc) B

Выражение, это значит, что в месте между, например, select и запятой может не только выбираться значение столбца (выполняться тривиальное действие):

select col1, -- извлекли содержимое колонки - вполне тривиальное действие
           col2 from table1

Но выполнятся более функциональное действие, требующее от планировщика запросов разобрать что-то, что находится до селекта и запятой (почему что-то? - это и есть выражение))) ):

select (col1 + col2) * 10 as result, -- а тут уже применили ариф. операции - написали выражение
           col2 from table1

В аргументах функции вы можете передавать не только значения, которые содержатся в колонках, но и как-то предварительно их вычислять с помощью арифметики, склеивания строк, преобразования типа, выбора логического варианта с помощью case, вставлять другую функцию и т.д.

Стандартная практика ведения истории изменения данных таблицы.
Вешаете триггер по операциям UPDATE, INSERT, DELETE перед их выполнением (опция before) на интересуемую таблицу и вставляете данные из атрибутов old.* триггера в таблицу истории.
Таблица истории:
history_id - идент. записи истории
next_history_id - идент. следующей записи истории в пределах одной записи отслеживаемой таблицы (у последней он null)
oper_type - тип операции (UPDATE, INSERT, DELETE - можно числами записать)
old.* - все атрибуты таблицы, значения до выполнения операции.
new.* - все атрибуты таблицы, которые пытались внести операциями UPDATE или INSERT. Этот набор нужен, если вы следите за историей на транзакциях, которые были откатаны назад (неудачные попытки). В этом случае, в триггере нужно указать специальную опцию, чтобы он работал в режиме автономной транзакции.
При внесении новой записи истории, в предыдущей записи по такому же первичному ключу отслеживаемой таблицы нужно добавлять next_history_id от history_id новой записи.
Таким образом в отслеживаемой таблице будет актуальное состояние записи, а в таблице истории - цепочка изменений записей.
По каждому первичному ключу записи отслеживаемой таблицы можно построить цепочку изменений по history_id и next_history_id.
А по next_history_id is null можно быстро получить последнее изменение из этой цепочки.
Естественно, к этим полям нужно добавить индексы.

1. Сделать правильную таблицу Client с полем год.
2. Создать индекс на поле год.
3. Сделать импорт из таблиц Client_ГОД в таблицу Client с указанием поля года.
4. Переписать запросы, чтобы присутствовала таблица Client в контексте нужного года (выборка с параметром год).
5. Если очень нужно ограничить выборку по нужному году (по соображениям разграничения прав), то для определенных запросов сделать view по нужному году, выдать права на view для определенного пользователя.

1. В качестве входных параметров никогда не использовались имена таблиц в подготовленных запросах - это попытка забивать микроскопом гвозди.
2. Метки для входных параметров - это не тип данных, это просто название места куда будет подставлено значение этой метки по ключу из массива значений.
Причем, именованные метки нужно связывать со значением с помощью специальной функции:

$stmt = $db->prepare("SELECT * FROM moya_tablitsa WHERE id = :metka_parametra_identifikatora");
$stmt->bindParam(':metka_parametra_identifikatora', 123);
$stmt->execute();

Но можно не использовать именованные метки (если их несколько в запросе, то нужно вставлять значения по порядку)

$stmt = $db->prepare("SELECT * FROM moya_tablitsa WHERE id = ?");
$stmt->execute([123]);

Можно использовать связывающую функцию, указав порядок метки.

$stmt = $db->prepare("SELECT * FROM moya_tablitsa WHERE id = ?");
$stmt->bindParam(1, 123); // 1 - это номер метки, 123 - значение параметра
$stmt->execute();

Подскажите пожалуйста - в каком направлении думать.

Подтянуть знания:
1. Псевдонимы таблиц и полей в SQL.
2. Соединения таблиц (join, left/right/cross join).
3. Использование группировок в выборке.
4. Агрегирующие функции (count, max, min и т.д.).
В перспективе:
5. Оконные функции.
6. Подзапросы для получения скалярного значения (используется в секции select или в where)
7. Подзапросы в секции from

Select w.`Код`, w.`Фамилия`, w.`Имя`, w.`Отчество`, 
           count(ch.*) as Child_Count -- кол-во детей
           -- count(distinct ch.`Фамилия`, ch.`Имя`, ch.`Отчество`, ch.`Дата рождения`) as Child_Count -- кол-во детей по группе уникальных полей по таблице Дети, без использования идентификатора
from `Список` w
join `Дети` ch on ch.`КодСотрудника`  = w.`Код`
group by w.`Код`, w.`Фамилия`, w.`Имя`, w.`Отчество`

Очевидно, что нужны алиасы к таблицам, особенно к тем, которые несколько раз присоединяются.

select psc.*, 
  pt1.`value` as `picture`, 
  pt2.`value` as `sort_pos`
 from `pref_site_content` as psc
    inner join `pref_site_tmplvar_contentvalues` as pt1 on pt1.`contentid` = psc.`id` and pt1.`tmplvarid` = 37 
    inner join `pref_site_tmplvar_contentvalues` as pt2 on pt2.`contentid` = psc.`id` and pt2.`tmplvarid` = 111 
    where psc.`id` not in (898, 899, 900, 902)
       and (`template` = 40 and `published` = 1) -- тут, возможно, тоже можно добавить, если в таблицах поля одинаково названы