файл отрицательного размера

В Debian’е 9.6 попробовал установить mysql, но вместо него поставилась mariadb.

Сервер автоматически запустился, но зайти в него от меня самого не получалось:

$ mysql -u root
ERROR 1698 (28000): Access denied for user 'root'@'localhost'

А с “-p” запрашивался пароль, но я его не знал – при установке сервера пароль ввести не просили.

Погуглил, запустил от рута mysql_secure_installation, ввёл там пароль, но клиентскую программу всё равно не пускали:

$ mysql -u root -p
Enter password: 
ERROR 1698 (28000): Access denied for user 'root'@'localhost'

А вот когда попробовал запустить mysql от рута, он успешно подключился к серверу вообще без пароля:

# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 1
Server version: 10.1.37-MariaDB-0+deb9u1 Debian 9.6

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

Посмотрел в таблицу mysql.user, там вполне был root@localhost с паролем и полными привилегиями, как обычно.

Ещё погуглил, и запустил там

GRANT ALL PRIVILEGES on *.* to 'root'@'localhost' IDENTIFIED BY 'ТОТжеСАМЫЙпароль';
FLUSH PRIVELEGES;

и хотя в mysql.user вроде ничего не поменялось, но “mysql -u root -p” стал работать от моего эккаунта.
А от рута просто так работать перестал:

# mysql 
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

Только с -p, и с тем же паролем работает, как обычно в mysql’е.

Оригинал этой записи в личном блоге.

Это такая система для аналитических запросов к гигантским базам данных, обновляемым в реальном времени. Изначально разрабатывалась для работы с Яндекс.Метрикой.
Брать тут, статья на хабре: https://m.habr.com/en/company/yandex/blog/303282/

P.S. Посмотрев на первую ссылку, я внезапно узнал, что у Яндекса уже почти два года как есть собственный домен первого уровня: yandex. У гугла, кстати, тоже: google. Это такая новая мода?

Оригинал этой записи в личном блоге.

а студент-двоечник.

Категории и тэги лежат в одной таблице. Зачем — непонятно, но это ещё фигня. Таблица выглядит так:

CREATE TABLE `wp_terms` (
  `term_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(200) NOT NULL DEFAULT '',
  `slug` varchar(200) NOT NULL DEFAULT '',
  `term_group` bigint(10) NOT NULL DEFAULT '0',
  PRIMARY KEY (`term_id`),
  UNIQUE KEY `slug` (`slug`),
  KEY `name` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Что такое term_group — загадка природы, там у всех записей 0.
slug — это URL-encoded name. Им лень было при обработке запросов в /tag/ и /category/ сделать url-decode и поискать по имени, лучше сделать лишнее поле. Причём поле это такой же длины, как и name, а один неанглоязычный символ из name в url-encoded виде занимает 6 байт, например буква “л” выглядит в slug как %d0%bb . А вот почему slug сделан уникальным ключом, а name неуникальным — загадка природы.

А тип записей в wp_terms вообще отсутствует. Он ВНЕЗАПНО лежит в другой таблице:

CREATE TABLE `wp_term_taxonomy` (
  `term_taxonomy_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `term_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  `taxonomy` varchar(32) NOT NULL DEFAULT '',
  `description` longtext NOT NULL,
  `parent` bigint(20) unsigned NOT NULL DEFAULT '0',
  `count` bigint(20) NOT NULL DEFAULT '0',
  PRIMARY KEY (`term_taxonomy_id`),
  UNIQUE KEY `term_id_taxonomy` (`term_id`,`taxonomy`),
  KEY `taxonomy` (`taxonomy`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Вот в ней в поле taxonomy хранит тип записи. В текстовом виде: “category”, “post_tag” или “link_category”. И в сочетании с term_id оно составляет уникальный ключ. То есть, если попытаться создать и категорию, и тэг с одинаковым именем, то в wp_terms будет только одна запись, а в wp_term_taxonomy – две, с одинаковым term_id. Но это такая редкость, что экономить единичные записи в таблице, существенно усложняя при этом поиск по имени (join двух таблиц вместо простого поиска в одной) — это идиотизм.

Что есть parent — я вообще не понял, там всегда 0. А count (руки оторвать за использование названий стандартных функций в качестве имён полей) по идее должен хранить количество постов, привязанных к данной категории или тэгу. И для большинства записей это действительно так. Но иногда..

mysql> select term_taxonomy_id, count from wp_term_taxonomy where term_taxonomy_id = 1;
+------------------+-------+
| term_taxonomy_id | count |
+------------------+-------+
|                1 |  1933 |
+------------------+-------+

mysql> select count(*) from wp_term_relationships where term_taxonomy_id = 1;
+----------+
| count(*) |
+----------+
|     3708 |
+----------+

Ничего общего.. И даже если посчитать только опубликованные посты (исключить черновики и старые версии), всё равно не совпадает:

mysql> select count(*) from wp_term_relationships r join wp_posts p on r.object_id=p.ID where r.term_taxonomy_id = 1 and p.post_status='publish';
+----------+
| count(*) |
+----------+
|     1936 |
+----------+

Оригинал этой записи в личном блоге.

Пытаюсь разобраться в структуре базы wordpress’а… Там есть таблица wp_comments, в ней, очевидно, лежат комментарии. Сотня:

mysql> select count(*) from wp_comments;
+----------+
| count(*) |
+----------+
|      101 |
+----------+

А ещё есть таблица wp_commentmeta, в которой лежит в шесть раз больше не пойми чего..

mysql> select count(*) from wp_commentmeta;
+----------+
| count(*) |
+----------+
|      667 |
+----------+

mysql> desc wp_commentmeta;
+------------+---------------------+------+-----+---------+----------------+
| Field      | Type                | Null | Key | Default | Extra          |
+------------+---------------------+------+-----+---------+----------------+
| meta_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| comment_id | bigint(20) unsigned | NO   | MUL | 0       |                |
| meta_key   | varchar(255)        | YES  | MUL | NULL    |                |
| meta_value | longtext            | YES  |     | NULL    |                |
+------------+---------------------+------+-----+---------+----------------+

meta_key там везде одинаковый:

mysql> select distinct meta_key from wp_commentmeta;
+-----------------------+
| meta_key              |
+-----------------------+
| _wp_trash_meta_status |
+-----------------------+

А значений у него целых два, 0 и 1:

mysql> select distinct meta_value from wp_commentmeta;
+------------+
| meta_value |
+------------+
| 1          |
| 0          |
+------------+

Но при этом имеющиеся там comment_id совершенно не совпадают с теми, что есть в wp_comments:

mysql> select count(*) from wp_commentmeta where comment_id in (select comment_id from wp_comments);
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

Я фигею, дорогая редакция.

Оригинал этой записи в личном блоге.

mysql> select count(*) from ext_requests;
+----------+
| count(*) |
+----------+
|  7460166 |
+----------+
1 row in set (11 min 34.88 sec)

Машина больше ничем не занималась, кроме обработки этого самого запроса.

Вот это тоже радует:

mysql> show tables;
+--------------------------------------+
| Tables_in_*****************          |
+--------------------------------------+
...
+--------------------------------------+
1586 rows in set (0.02 sec)

 

Оригинал этой записи в личном блоге.

Ну конечно, я на них наступил.

Типичная последовательность действий при работе с базой данных: prepare(), execute(), если надо прочитать результат – fetch(), ну и в конце finish(). И до сих пор всё работало.

И тут ВНЕЗАПНО оказалось, что если выполняется не обычный SQLный оператор, а хранимая процедура (посредством EXECUTE PROCEDURE), то возникшая при выполнении ошибка после execute() никак не проявляется. Типа, всё нормально выполнилось. А вот когда потом делаешь fetch(), тут-то ошибка и вылезает. Более того, если процедура ничего не возвращает, то ошибка не проявляется вовсе. И процедура, кажется, вообще не выполняется, пока не сделаешь fetch(). Да-да, fetch(), который заведомо ничего вернуть не может.

В документации, естественно, эта замечательная особенность не описана. И я, как обычно, на эти грабли наступил и потратил полдня, чтоб понять, какого хрена оно молча не работает.

Оригинал этой записи. Комментировать можно тут или там.

А вот кто-нибудь может объяснить, что делает аксессовская функция datediff(“w”,,)?
Если я правильно понял описание, то она возвращает разницу между двумя временнЫми метками в… днях недели.

И конечно, я наткнулся на кусок кода, который ЭТО использует. Если найду автора, обязательно опубликую его мысли на тему, зачем ему это понадобилось.

А пока вопрос к залу: правильно ли я понял смысл этого параметра, и как ЭТО записать  в человеческих терминах?

Оригинал этой записи в личном блоге.

ну раз уж он сегодня случился, то:
не ленитесь в операторах SELECT и INSERT явно перечислить имена полей. Даже если их много.

Это сэкономит вам много времени и нервов.
Когда какому-нибудь доброму человеку придёт в голову ночью, тихонько, никому не говоря, поменять структуру таблицы.

тут. Рассматриваются, натурально, проблемы структуры баз данных с точки зрения однополых браков и около. Длинно, но заслуживает прочтения :)

via lhovitch