Тестова постановка

Ще използваме примерната база от данни World и по-специално нейната таблица city, която има 4079 реда. Създаваме общо 8 тестови съхранени процедури:

DELIMITER //
CREATE PROCEDURE test1_1(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
      SELECT name FROM city 
      ORDER BY RAND() LIMIT 1;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test1_10(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
      SELECT name FROM city 
      ORDER BY RAND() LIMIT 10;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test1_100(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
      SELECT name FROM city 
      ORDER BY RAND() LIMIT 100;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test1_1000(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
      SELECT name FROM city 
      ORDER BY RAND() LIMIT 1000;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test6_1(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
     SELECT city.name
     FROM city JOIN
          (SELECT CEIL(RAND() * (SELECT MAX(id) FROM city)) AS num, 
                  @num:=@num+1 
           FROM (SELECT @num:=0) AS a, city LIMIT 1) AS tmp 
          ON tmp.num = city.id;
     ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test6_10(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
     SELECT city.name
     FROM city JOIN
          (SELECT CEIL(RAND() * (SELECT MAX(id) FROM city)) AS num, 
                  @num:=@num+1 
           FROM (SELECT @num:=0) AS a, city LIMIT 10) AS tmp 
          ON tmp.num = city.id;
     ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test6_100(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
     SELECT city.name
     FROM city JOIN
          (SELECT CEIL(RAND() * (SELECT MAX(id) FROM city)) AS num, 
                  @num:=@num+1 
           FROM (SELECT @num:=0) AS a, city LIMIT 100) AS tmp 
          ON tmp.num = city.id;
     ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test6_1000(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
     SELECT city.name
     FROM city JOIN
          (SELECT CEIL(RAND() * (SELECT MAX(id) FROM city)) AS num, 
                  @num:=@num+1 
           FROM (SELECT @num:=0) AS a, city LIMIT 1000) AS tmp 
          ON tmp.num = city.id;
     ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

Резултати

Резултатите от тестовете са показателни:

CALL test1_1(1000);
Query OK, 0 rows affected (4.31 sec)

CALL test6_1(1000);
Query OK, 0 rows affected (0.69 sec)

CALL test1_10(1000);
Query OK, 0 rows affected (5.92 sec)

CALL test6_10(1000);
Query OK, 0 rows affected (4.01 sec)

CALL test1_100(1000);
Query OK, 0 rows affected (50.69 sec)

CALL test6_100(1000);
Query OK, 0 rows affected (50.97 sec)

CALL test1_1000(1000);
Query OK, 0 rows affected (10 min 2.53 sec)

CALL test6_1000(1000);
Query OK, 0 rows affected (9 min 54.92 sec)

Съвсем ясно се вижда, че първоначалната значителна преднина на test6 (модифицирания JOIN метод) се губи много бързо. Докато при извеждането на 10 произволни реда все още има някаква (но вече не голяма) преднина, то при 100 произволни реда вече тестовете са с изравнена бързина. Това се потвърждава и от теста с 1000 реда, при който разликите наистина са в рамките на нормалното отклонение.

Разлики между методите

Трябва сериозно да се отбележи една много важна разлика между двата метода – ORDER BY RAND() LIMIT X връща точно X различни реда (т.е. не са напълно произволни, а са зависими един от друг), докато оптимизирания JOIN метод може да върне и повтарящи се редове (имаме независимост между произволните редове). Ето пример за това:

SELECT DISTINCT name FROM city 
ORDER BY RAND() LIMIT 1000;
...
1000 rows in set (0.02 sec)

SELECT DISTINCT city.name
FROM city JOIN
     (SELECT CEIL(RAND() * (SELECT MAX(id) FROM city)) AS num, @num:=@num+1 
      FROM (SELECT @num:=0) AS a, city LIMIT 1000) AS tmp 
     ON tmp.num = city.id;
...
861 rows in set (0.00 sec)

Виждате, че при оптимизирания JOIN метод се получиха 139 повторения, докато при ORDER BY RAND() нито едно.

Другата, наистина много важна разлика е, че JOIN метода има съществена нужда от поредни идентификационни номера без дупки! При ORDER BY RAND() това не е така. Ако ние имаме нужда от изтриване на редове от таблицата, то поддържането на поредни идентификационни номера не е никак приятна, нито пък препоръчителна операция (особено ако числата са по първичен ключ).

Заключение

Когато очакваме извеждане на резултат, то обикновено ние не се интересуваме от повтарящи се редове, а напротив – не ги искаме. Поради тази причина при извикване на повече от 10 произволни реда ще се окаже, че ORDER BY RAND() е по-добрия метод.

Когато очакваме наистина произволни редове, а не различни (зависими от предишните) такива, то може да използвате JOIN метода, като преди това трябва да сте сигурни, че в реда няма дупки между идентификационните номера. Ако има такива, то ще се наложи да ги пренаредите с UPDATE заявка, която при всички положения ще е много тежка операция (допълнително ще трябва да се погрижите за AUTO_INCREMENT стойността, която ще трябва да се намали).

Нека преди да започнем с примери да създадем тестова база от данни. Тя ще се състои от две таблици – потребители и публикации. Всеки потребител има уникален номер и име. В публикациите пазим уникален номер, номер на автор, заглавие, съдържание, дата на създаване и номер на статия, на която се отговаря (ако се публикува отговор на друго съобщение). Ще има два вида статии – едните ще са “главни” (те ще имат попълнено заглавие, но няма да имат попълнена стойност за “отговор на”), а другите ще са “отговори” (те ще имат попълнен “отговор на”, но няма да имат заглавие). Ето и въпросните две таблици:

CREATE DATABASE fts
  DEFAULT CHARACTER SET utf8
  DEFAULT COLLATE utf8_general_ci;

USE fts;

CREATE TABLE users(
  id SMALLINT UNSIGNED PRIMARY KEY,
  username VARCHAR(30) NOT NULL UNIQUE
)ENGINE=InnoDB;

CREATE TABLE posts(
  id INT UNSIGNED PRIMARY KEY,
  author SMALLINT UNSIGNED,
  FOREIGN KEY(author) REFERENCES users(id),
  title VARCHAR(255) NULL DEFAULT NULL,
  data TEXT NOT NULL,
  created DATETIME NOT NULL,
  reply_to INT UNSIGNED NULL DEFAULT NULL,
  FOREIGN KEY(reply_to) REFERENCES posts(id)
)ENGINE=InnoDB;

Нека създадем и един тригер, който ще се грижи за интегритета на данните:

DELIMITER //
CREATE TRIGGER post_integrity_check
BEFORE INSERT ON posts FOR EACH ROW
BEGIN
  DECLARE errormsg VARCHAR(255);
  DECLARE main_post_title VARCHAR(255);
  IF NEW.title IS NULL
  THEN
    IF NEW.reply_to IS NULL
    THEN
      SET errormsg = "Основните съобщения трябва да имат заглавие";
      SIGNAL SQLSTATE '45000' SET message_text = errormsg;
    ELSE
      SELECT title INTO main_post_title
      FROM posts
      WHERE id = NEW.reply_to;
      IF main_post_title IS NULL
      THEN
        SET errormsg = "Отговарите могат да са само към главно съобщение";
	SIGNAL SQLSTATE '45000' SET message_text = errormsg;
      END IF;
    END IF;
  ELSE
    IF NEW.reply_to IS NOT NULL
    THEN
      SET errormsg = "Отговорите не могат да предефинират заглавието";
      SIGNAL SQLSTATE '45000' SET message_text = errormsg;
    END IF;
  END IF;
END//
DELIMITER ;

Нека вмъкнем примерни данни. В случая взехме няколко произволни съобщения от форума OFFRoad-Bulgaria.com. Изтеглете файла със заявките от тук (ако не виждате текста – кодировката на файла е UTF8).

Ето една най-проста примерна заявка – изкарайте информация за тема 10 и всички нейни отговори, като сортирате по дата на въвеждане в базата от данни:

SELECT IF(posts.title IS NOT NULL, posts.title, 'REPLY') AS title, 
       users.username AS author, posts.created AS created, posts.data AS contents
FROM posts JOIN users ON posts.author = users.id
WHERE posts.id = 10 OR posts.reply_to = 10
ORDER BY posts.created\G

Сега да пристъпим към същината на темата – fulltext търсене. Досега знаем как можем да търсим шаблони в текстови полета чрез използване на оператор LIKE. Например ако искаме да намерим идентификационните номера на всички съобщения, които съдържат думата “Лада” някъде в името на заглавието (ако е основно съобщение, защото отговорите нямат заглавия) или някъде в съдържанието си, то можем да направим следното:

SELECT id FROM posts
WHERE title LIKE '%Лада%' OR data LIKE '%Лада%';
+----+
| id |
+----+
|  1 |
|  5 |
+----+
2 rows in set (0.00 sec)

Това е много лошо решение, защото:

• Търсенето по този начин е изключително бавно. Дори да съществуват индекси те никога няма да се използват. Проверете – направете индекс по колона “title” и направете EXPLAIN на заявката – ще видите, че този индекс няма да присъства дори в “possible keys”. Причината е, че нашия шаблон започва с “%”;
• Няма никакви критерии за сравнение “кой от резултатите е по-точен”. Ако например намерените резултати са два идентификационни номера “X” и “Y”, то не можем да кажем, кое от двете попадения е по-подходящо за нас;
• Следствие от недостатъка на предишната точка е, че при нарастването на базата от данни ще имаме все повече и повече резултати при стандартни търсения по обикновена дума и резултатните ни таблици ще стават все по-големи. При липсата на очевидна подредба потребителят ще се “загуби” в резултатите. Няма никаква гаранция, че това, което излиза първо ще е това, което е “най-точно” попадение.

С други думи на този етап ние искаме по някакъв начин да разширим стандартното търсене в текста с нещо допълнително – критерий за сравнение между резултатите (за да можем да ги подреждаме преди да ги изпратим към потребителя) и наличието на индекси (с което търсенето да бъде бързо). Решението e:

Създаване на Fulltext индекс

За да създадете въпросния индекс трябва да изпълните следната команда:

ALTER TABLE posts ADD FULLTEXT(title, data);

Като колони може да подавате само CHAR, VARCHAR или *TEXT типове данни. В последствие вие може да търсите чрез командата “MATCH (…) AGAINST (…)” по колоните описани в индекса. Например ако искаме да направим нещо подобно на предложеното по-горе търсене, то ще напишем:

SELECT id FROM posts
WHERE MATCH(title, data) AGAINST ('Лада');
+----+
| id |
+----+
|  1 |
|  5 |
+----+
2 rows in set (0.00 sec)

Тук обаче нещата са се получили по доста различен начин. Въпросният индекс всъщност се състои от думи, тяхната “тежест” и референции към редовете, в които се съдържат. Тежестта на всяка дума зависи от това “в колко от редовете е налична” (по-рядка дума ще има по-голяма тежест и обратно). Наличието на думи от търсената фраза в текста ще добавят различни “тегла”. Именно общото тегло можем да използваме, за да сортираме нашите заявки. Ето как можем да видим въпросните тегла:

SELECT id, MATCH(title, data) AGAINST('Лада') AS score
FROM posts
WHERE MATCH(title, data) AGAINST ('Лада')
ORDER BY score DESC;
+----+--------------------+
| id | score              |
+----+--------------------+
|  1 | 1.0845428705215454 |
|  5 | 0.9728003144264221 |
+----+--------------------+
2 rows in set (0.00 sec)

Имайте в предвид, че в реално приложение няма нужда да слагате MATCH…AGAINST във връщаните колони и ORDER BY score в заявката. Ако те липсват, то MySQL автоматично ще сортира резултатната таблица по същия начин, както показания по-горе.

Колкото по-голяма е общата тежест, толкова по-добро е попадението. Наличието на MATCH…AGAINST… два пъти (един път в колоните на SELECT и един път в WHERE) НЕ добавя допълнително натоварване – MySQL ще направи търсенето само веднъж и ще го преизползва.

В MySQL 5.6 има три вида търсене. Ще разгледаме всеки един от тях:

Търсене с естествен език (IN NATURAL LANGUAGE MODE)

Това е търсенето по подразбиране. Ако напишете MATCH(колони) AGAINST (“text”), то все едно сте написали MATCH(колони) AGAINST (“text” IN NATURAL LANGUAGE MODE). Този метод за търсене е възможно най-елементарен – просто се добавя тежестта на всяко едно попадение към общата тежест за всеки ред. Отсъствието на дума НЕ намалява общата тежест. Нека го демонстрираме с още три примера свързани с предишния:

SELECT id, MATCH(title, data) AGAINST('мост') AS score
FROM posts
WHERE MATCH(title, data) AGAINST ('мост')
ORDER BY score DESC;
+----+--------------------+
| id | score              |
+----+--------------------+
| 11 | 1.0986145734786987 |
| 10 | 0.9155634045600891 |
+----+--------------------+
2 rows in set (0.00 sec)

SELECT id, MATCH(title, data) AGAINST('мост Лада') AS score
FROM posts
WHERE MATCH(title, data) AGAINST ('мост Лада')
ORDER BY score DESC;
+----+--------------------+
| id | score              |
+----+--------------------+
| 11 | 1.0986145734786987 |
|  1 | 1.0845428705215454 |
|  5 | 0.9728003144264221 |
| 10 | 0.9155634045600891 |
+----+--------------------+
4 rows in set (0.00 sec)

SELECT id, MATCH(title, data) AGAINST('мост Лада Нива') AS score
FROM posts
WHERE MATCH(title, data) AGAINST ('мост Лада Нива')
ORDER BY score DESC;
+----+--------------------+
| id | score              |
+----+--------------------+
|  5 |   2.61989426612854 |
|  1 |  2.169085741043091 |
| 11 | 1.0986145734786987 |
| 10 | 0.9155634045600891 |
+----+--------------------+
4 rows in set (0.00 sec)

Какво се случи:

• Думата “Лада” е налична само в постове 1 и 5 (проверете);
• Думата “мост” е налична само в постове 10 и 11 (проверете);
• При търсене на “мост Лада” се взеха всички редове, които съдържат думите “мост” и “Лада” и всеки ред получи своята тежест спрямо наличието на думите в него;
• При търсене на “мост Лада Нива” ние добавихме още една ключова дума – “Нива”. Тя очевидно НЕ е налична в постове 10 и 11, но е налична в 1 и 5. Тя съответно добави по-голяма тежест при тях.

Все пак можем да забележим нещо важно – думите “Лада” и “Нива” са едновременно налични и в двете съобщения 1 и 5, но те получиха съвсем различни оценки. Това е така, понеже освен “тежестта на думата” и нейното “наличие или отсъствие” се пресмятат още допълнителни неща – колко пъти се срещат попаденията в реда и колко уникални думи има в реда.

Важно е да се отбележи, че не се търси по абсолютно всичко. Търсената фраза може да съдържа всякакви символи, но за “дума” ще се разчете само наличието на букви, цифри, долна черта или една(!) единична кавичка. Думите се разделят чрез разделители. Стандартните разделители са празен интервал, запетайка и точка. Наличието на “специален символ” (нито един от посочените дотук) също ще бъде счетен за разделител на думи. Тоест “мост$Лада” ще е същото като “мост Лада”.

Допълнително важат и следните правила:

• Всяка “прекалено кратка” дума ще бъде пропусната (не оказва влияние на резултата). При InnoDB по подразбиране това са двубуквените думи. Възможно е да променяте тази минимална дължина на дума чрез променливата innodb_ft_min_token_size. Това ограничение е важно, за да се премахнат попадения от предлози, съюзи и частици като “на”, “ще”, “до”, “и”, “по” и т.н. Имайте го в предвид, понеже може да доведе до неочаквани резултати. Ако например сте направили минималната дължина на дума от четири букви (както например е по подразбиране в MyISAM), то търсенето на думата “УАЗ” ще е невъзможно и няма да върне никакъв резултат (бел. ред. сега разбирате и причината, поради която в много сайтове когато търсите нещо се изисква “да въведете поне X символа”).;
• Думи от т.нар. “стоп списък” (stopwords) ще бъдат пропускани. Ще разгледаме този списък по-надолу.
• Стандартно (освен ако не сте избрали специфичен collation) не се прави разлика между малки и големи букви;
• Добре е да отбележим и една важна разлика между Full Text Search в InnoDB и MyISAM. При MyISAM ако една дума присъства в повече от 50% от редовете, то тя ще бъде пропусната (този процент може да се коригира). При InnoDB на този етап не е така.

Разширено търсене с естествен език (WITH QUERY EXPANSION)

Понякога търсените фрази съдържат рядко използвани ключови думи, които имат значение на синоними на други, които са с по-широк спектър. Нека например предположим, че един човек търси наличието на думата “21213″ и по стандартния метод тя връща само едно единствено попадение. Да, но реално за човека думата “21213″ всъщност означава “модел 21213 на Лада Нива”, т.е. той би очаквал да получи и статии свързани и с думите “Лада” и “Нива”, а не само с търсената от него “21213″. Това е реален проблем, защото СУБД няма как да има информация за тази допълнителна връзка между думите.

Именно тук се намесва “разширеното търсене”. При него практически търсенето се извършва на две стъпки:

1. На първата стъпка се намират редовете с търсената дума. От тях се подбират други ключови думи, които MySQL определя като “значими” (с достатъчно голяма тежест, но не уникални, а общи за въпросните редове). Тези нови ключови думи се предполага, че са значими за редовете;
2. Прави се повторно търсене, но този път се добавят и подбраните нови ключови думи.

Ето един пример:

SELECT id, MATCH(title, data) AGAINST('Уазка') AS score
FROM posts
WHERE MATCH(title, data) AGAINST ('Уазка')
ORDER BY score DESC;
+----+--------------------+
| id | score              |
+----+--------------------+
| 10 | 1.4016318321228027 |
+----+--------------------+
1 row in set (0.00 sec)

SELECT id, MATCH(title, data) 
           AGAINST('Уазка' WITH QUERY EXPANSION) AS score
FROM posts
WHERE MATCH(title, data) 
      AGAINST ('Уазка' WITH QUERY EXPANSION)
ORDER BY score DESC;
+----+--------------------+
| id | score              |
+----+--------------------+
| 10 |   72.7892074584961 |
| 11 |  5.612302303314209 |
|  8 | 3.1514804363250732 |
|  3 |  2.191800594329834 |
|  6 |  1.733217716217041 |
|  2 | 0.8657563924789429 |
|  7 | 0.7457319498062134 |
+----+--------------------+
7 rows in set (0.02 sec)

Както се вижда ясно думата “Уазка” е налична само в една статия, но при разширеното търсене бяха отсети още няколко такива. Излезли са допълнителни статии, при това никак не лошо подредени по значимост. По този начин СУБД успя да свърже “Уазка” с “УАЗ” и някои други ключови думи.

От друга страна трябва да знаете, че разширеното търсене почти винаги вмъква много “шум” в резултатите, т.е. излизат резултати, които наистина нямат нищо общо с търсеното. По-често тяхната обща тежест е ниска (можете ги отрежете с LIMIT или с HAVING(score>…)), но понякога може да получат и незаслужено висока оценка. Принципното правило за зависимостта между “шума” и “правилните резултати” е следното: колкото по-кратка е фразата, толкова по-малък шум се очаква и обратно – при дълги фрази очаквайте по-голям шум.

Булево търсене (IN BOOLEAN MODE)

Булевото търсене вече ни дава част от възможностите на истинска “търсачка” така, както я познаваме от Google, Yahoo, Altavista и подобни. При него важат същите правила, както при нормалното търсене с естествен език, но има допълнителни оператори, които ни помагат значително да прецизираме. Те са следните:

• Без оператор: Думата може да присъства (ще придаде тежест), но може и да не присъства. Абсолютно аналогично е като резултат при нормалното търсене – между търсените думи във фразата се слага логическо “или”;
• Оператор “+”: Поставяйки “+” пред дума в търсената фраза ние указваме, че думата е задължителна. Например ако търсим за “Лада Нива”, то стандартно бихме могли да получим попадения съдържащи само “Лада” и съдържащи само “Нива”. Ако търсим за “+Лада +Нива”, то ние указваме, че е напълно задължително и двете думи да присъстват в резултатните редове;
• Оператор “-”: Действието му е точно обратното на “+” – този оператор указва, че указаната дума е задължително да НЕ присъства в резултатните редове. Например “+Лада -Калина” ще върне всички редове с дума “Лада”, но от тях ще пропусне тези, в които присъства дума “Калина”;
• Оператор “~”: С него се прави “обратна тежест”, т.е. думата след него ще намали резултатите, вместо да ги увеличи. Един вид това е по-слабо действие спрямо оператор “-” – не желаем напълно за изключваме резултатите, но все пак ги отчитаме като по-лоши;
• Оператор “@<разстояние>”: Указва минимално разстояние (в байтове), което трябва да е между думите. Например ако търсим за ‘ “Лада Нива” @20′, то системата ще даде тежест на думите “Лада” и “Нива”, но само тогава, когато те са на разстояние повече от 20 байта една от друга. Задължително е да ограждате ключовите думи (може да са повече от две) с двойни кавички и да слагате оператора след тях. Този оператор е удобен тогава, когато вие желаете да взимате резултати по търсените думи, но искате да избегнете конкретна често срещана комбинация от тях. Този оператор е наличен само за InnoDB;
• Ограждащи скоби “(” и “)”: Групират думи в “подизрази”. Използва се в комбинация с друг оператор, за да се даде общо значение за две фрази. Например “+(Лада Нива)” ще изиска и двете думи да са налични (все едно сме сложили + и пред двете);
• Оператори “>” и “<”: Увеличава или намалява тежестта на думата. Например търсенето на “+Двигател +(>бензинов <дизелов)” ще намери резултати едновременно за бензиновите и за дизеловите двигатели, но тези, които са бензинови ще получат по-голяма тежест;
• Оператор “*”: Има действието на “%” при търсене с LIKE, с тази разлика, че може да се използва само в края на думата. Тоест този оператор указва, че търсената дума “започва с…”. Например ако търсите “УАЗ*”, то ще получите и резултати “УАЗ”, “УАЗа” и “УАЗка” (и др. думи започващи с “уаз”, ако има такива). Тук “прекалено късите” думи не се пропускат!;
• Точна фраза: Когато оградите фраза с двойни кавички, то ще търсите “точно съвпадение”. Изключение се прави само ако е използван оператора за разстояние (описан по-горе).

ВАЖНО: При използване на режим “IN BOOLEAN MODE” НЕ се извършва автоматично сортиране!!!

Примери:

1. Търсим статиите с точна фраза “Лада Нива”, но без тези, които включват думата “метан”:

SELECT id, MATCH(title, data)
           AGAINST('"Лада Нива" -метан' IN BOOLEAN MODE) AS score
FROM posts
WHERE MATCH(title, data)
      AGAINST('"Лада Нива" -метан'  IN BOOLEAN MODE)
ORDER BY score DESC;

2. Търсим статиите, в които се коментира едновременно УАЗ и ГАЗ (и техните вариации като УАЗ469, ГАЗ66 и т.н.):

SELECT id, MATCH(title, data)
           AGAINST('+(УАЗ* ГАЗ*)' IN BOOLEAN MODE) AS score
FROM posts
WHERE MATCH(title, data)
      AGAINST('+(УАЗ* ГАЗ*)' IN BOOLEAN MODE)
ORDER BY score DESC;

Стоп думи (STOPWORDS)

Както беше споменато в началото, “стоп думите” са такива, които се срещат често в езика и би следвало да се пропускат като незначителни. MySQL има малък набор от такива думи на английски език. Те се намират в база от данни “information_schema” в таблица “innodb_ft_default_stopword”. Ще видите, че таблицата има единствена колона с име “value” и е от тип “varchar(30)”.

Ако желаете вие сами да си съставите списък със “стоп думи”, то е необходимо да създадете нова таблица със същата структура, както innodb_ft_default_stopword, т.е.:

CREATE TABLE yourdb.stopwords(
  value VARCHAR(30) PRIMARY KEY
)ENGINE = InnoDB;

След което е нужно да пренасочите глобалната променлива innodb_ft_server_stopword_table да сочи към нея:

SET innodb_ft_server_stopword_table = "yourdb/stopwords";

Разбира се може да укажете да се зарежда винаги при стартиране на сървъра чрез my.cnf.

Ограничения

На този етап (към версия 5.6.5) има редица ограничения към използването на Fulltext търсене. Ето трите най-съществени от тях:

• Не се поддъжа при partitioning;
• В InnoDB може да правите не повече от един Full-Text индекс на таблица;
• Ако правите индекс по повече от една колона (както е в примера по-горе), то всички колони трябва да са от един и същи тип и collation;
• В Against може да се подава само константен низ (т.е. не може да се подават стойности от променливи).

Зад сцената

За разлика от MyISAM, където индекса се поддържа като специално B+ дърво, в InnoDB се използват помощни релационни таблици. Това разбира се има своите предимства и недостатъци. Предимствата са по-голяма скалируемост и евентуална паралелизация, от което и лесно поддържане на конкурентни транзакции (при MyISAM транзакции няма, с което и B+ дървото излиза като по-добрия избор). В случая обаче е важно да разберем по какъв начин се обновява индекса при различните видове операции за промяна на данните:

• Промяна на индекса само при достигане COMMIT: Индекса се променя винаги само и единствено при завършване на транзакция. Междинните промени вътре в транзакция не се отчитат. Ако имате транзакция, в която вмъквате/променяте/изтривате данни, то вие няма да видите промени във Full-Text индекса дори вътре в самата транкация. Ще видите промените чак след като я завършите с команда COMMIT;
• INSERT заявки: При завършване на insert заявка промените във Full-Text индекса се записват в специален кеш, който по подразбиране е 32MB и се контролира от променливата innodb_ft_cache_size. Този кеш се прехвърля в “индексните таблици” на дисковото устройство тогава, когато се запълни (или когато сървъра получи команда за изключване). Ако сървъра бъде спрян по неестествен начин, то при следващото включване се извършва синхронизация на кеша с физически записаните данни;
• UPDATE заявки: Обновяването на индексните таблици се извършва директно върху индексните таблици при достигането на COMMIT на транзакцията. Това е “скъпа операция”, защото често налага обновяване на множество редове от тях;
• DELЕTE заявки: Операциите за изтриване са доста бързи, понеже реално не се изтриват редове от индексните таблици. Вместо това се записва уникалния номер (FTS_DOC_ID – виж следващия раздел) в специална помощна таблица за “изтрити редове”. В последствие, когато се прави търсене, MySQL ще се обърне към тази таблица с изтрити редове, за да ги филтрира от резултатната таблица. Така DELЕTE заявките стават прости и бързи, понеже въобще не променят индекса, но от друга страна при продължително изпълнение на такива се получава постоянно намаляване на бързодействието на MATCH… AGAINST заявките, както и заемане на все по-голямо и по-голямо количество информация (индексите продължително растат). Решението на този проблем е да изтриете индекса и да го създадете наново. Това може да отнеме значително време при големи таблици. Алтернативно може да дадете стойност “1″ на глобалната променлива innodb_optimize_fulltext_only, след което да извършите команда OPTIMIZE TABLE… на въпросната таблица. Така ще се изпълнят до “innodb_ft_num_word_optimize” на брой (по подразбиране 2000) промени по индекса.

Допълнителни уточнения

Поддържането на Full-Text индекс е “скъпа” операция, която отнема доста ресурси. Забележете, че вмъкването или промяната на информация в таблица води до мащабно преструктуриране и обновяване на целия индекс. Поради тази причина, особено при големи обеми от данни, може да се окаже така, че при добавянето или променянето на няколко реда в таблица ще е по-добре да премахнете индекса, да добавите данните и след това да създадете индекса отново. Това често се използва от големите системи – при тях програмните продукти правят промените в таблиците на т.нар. “batches”, при които Full-Text индексите се пресъздават на всеки “batch”.

Full-Text индексите използват колона в таблицата с име “FTS_DOC_ID” (винаги с главни букви) от тип BIGINT UNSIGNED с AUTO_INCREMENT (източник). В бъдеще се предвижда да може да указвате и друга колона с произволно име, която да замести FTS_DOC_ID. Ако такава колона няма, то ще бъде създадена и по нея ще бъде създаден индекс (но създадената автоматично колона ще бъде “скрита” за вас, т.е. няма да я виждате). В редица случаи може да сметнете за подходящо вие сами да си създадете такава колона, особено тогава, когато вашата таблица има нужда от първичен ключ с “id”-та – тогава ще можете да споделите тази колона както за ваш първичен ключ, така и за Full-Text индекса. Освен това се използва и уникален индекс с име FTS_DOC_ID_INDEX, които също може да създадете. Или казано по друг начин – ако използвате Full-Text индекси, то е добре вашата таблица да има следната структура:

CREATE TABLE tbl(
FTS_DOC_ID BIGINT unsigned NOT NULL AUTO_INCREMENT,
PRIMARY KEY (FTS_DOC_ID),
...
) ENGINE=InnoDB;

CREATE UNIQUE INDEX FTS_DOC_ID_INDEX ON tbl(FTS_DOC_ID);

Не е задължително FTS_DOC_ID да е PRIMARY KEY – може спокойно да използвате друг ключ. В този случай FTS_DOC_ID трябва допълнително да го ограничите с NOT NULL и UNIQUE (за да предотвратите вмъкването на невалидни данни в последствие).

Друга оптимизация може да се получи при използване на InnoDB с Full-Text индекс на многопроцесорни (многоядрени) компютри (забележете, че това е нововъведение и MyISAM не се възползва от многопроцесорните системи при FT индекси). Броят на нишките, които работят паралелно с Full-Text индекса се контролира от променливата InnoDB_ft_sort_pll_degree (по подразбиране със стойност 2, т.е. 2 нишки). Възможните стойности могат да са степени на двойката и е препоръчително да изберете по-голям или равен на броя на процесорите (ядрата).

Използването на оператор “@<разстояние>” в булевото търсене на този етап прави заявките за търсене значително по-бавни. При оператор “*” също се наблюдава забавяне спрямо другите оператори, но определено е на приемливо ниво.

Естествено може да създавате Full-Text индекс и при самото създаване на таблицата (т.е. без да използвате ALTER TABLE, както беше в примера по-горе). Това става чрез:

CREATE TABLE tbl(
...
FULLTEXT(<колона/и>),
...
) ENGINE=InnoDB;

Или алтернативно на ALTER TABLE може да добавите индекса чрез специална заявка:

CREATE FULLTEXT INDEX idx 
ON <таблица>(<колона/и>);

Задача: В примерната база от данни направете така, че отговорите на статии да приемат автоматично заглавието на главната статия, на която те отговарят.

Точно като за шофьор на Лада Нива!

… си правим удобства…

… но все още ни липсва електрически ток, за да гледаме телевизия…

Жалко, че от общината минаха и ни прибраха удобствата с камион за боклук…

В Лада Нива има два основни блока с предпазители (бушони) – голям и малък. И двата се намират отпред в ляво спрямо шофьора, точно зад лоста за отваряне на предния капак. Бушонните табла са с пластмасов предпазен капак, който се сваля целия и на който са обозначени номерата на бушоните. Големият блок с предпазители има 10 бушона, а малкия 6 (т.е. общо са 16). Използват се “пръчковидни” бушони, а не ножични. При ВАЗ 21214 има още един блок с четири бушона вляво при компютъра. Ето какво предпазват съответните бушони според официалното ръководство на ВАЗ 21213:

1. 16A
   • Електродвигател на вентилатора за отоплението;
   • Реле на моторчето за миене на предните фарове;
   • Електродвигател на моторчето за миене на предните фарове (само в процес на миене, но не при стартиране и извеждане в изходна позиция след спиране!);
   • Ключ (реле) за включване на отоплението на задното стъкло;
   • Електродвигател на моторчето за задната чистачка;
   • Електродвигател на казанчето за пръскалката на задното стъкло;
   • Електродвигател на казанчето за пръскалките на предното стъкло.
2. 8A
   • Моторче за предните чистачки (реле и електродвигател);
   • Мигачи, бутон за аварийни светлини и лампи по таблото свързани с мигачите;
   • Фарове за заден ход;
   • Генератор;
   • Контролна лампа за зареждане на акумулатора;
   • Контролна лампа за блокиран междуосев диференциал;
   • Контролна лампа за ръчна спирачка;
   • Контролна лампа за ниво на спирачната течност;
   • Контролна лампа за маслото;
   • Указател за температурата на охлаждащата течност;
   • Указател за нивото на горивото в резервоара;
   • Тахометър (оборотомер).
3. 8A
   • Преден ляв фар на дълги светлини;
   • Контролна лампа за включени дълги светлини (включва се само ако е включена контролната лампа за габаритни светлини).
4. 8A
   • Преден десен фар на дълги светлини.
5. 8A
   • Преден ляв фар на къси светлини.
6. 8A
   • Преден десен фар на къси светлини.
7. 8A
   • Преден ляв фар за габаритни светлини;
   • Заден десен фар за габаритни светлини;
   • Крушки за осветление на задния номер;
   • Контролна лампа за включени габаритни светлини.
8. 8A
   • Преден десен фар за габаритни светлини;
   • Заден ляв фар за габаритни светлини;
   • Лампи за осветление на таблото;
   • Лампа на ключа за управление на вентилатора на парното;
   • Лампа за осветяване на запалката.
9. 16A
   • Нагревател за задното стъкло;
10. 16A
    • Клаксон;
    • Цокъл за лампа под предния капак;
    • Плафони за осветление на купето;
    • Задни стопове;
    • Фарове за мъгла.
11. Не се използва.
12. Не се използва.
13. 8A
    • Електродвигател на моторчето за миене на предните фарове (в момент на включване и в процес на прибиране на чистачките в начална позиция при спиране);
    • Ключ (реле) за чистачките на предното стъкло;
    • Електродвигател за пръскалките на фаровете – доколкото знам двигателя е един общ на казанчето за чистачки, но пък аз нямам чистачки на фаровете тъй или иначе така, че може да бъркам. Възможно е да има различни по вид казанчета и при някои да има два електромотора.
14. Не се използва.
15. 16A
    • Запалка.
16. Не се използва.

При някои по-стари модификации (зависи от годината на производство) запалката може да се намира на 10 бушон. При други (още по-стари) е възможно запалката да е на 13 бушон, като при тях 13-ти бушон е 16А, а 10-ти 8А (информация от niva-faq.msk.ru).

При ВАЗ 21214, както вече споменах по-горе, има четири допълнителни бушона. Първият и третия (по 15А) контролират компютъра и инжекциона, а четвъртия (отново 15А) контролира релетата на вентилаторите за охлаждане, датчиците обслужващи инжекциона и датчиците по охладителната система. Вторият е 30А и нямам представа какво обслужва, най-вероятно може би не се използва. Доколкото знам електродвигателите на вентилаторите за охлаждане си имат самостоятелни бушони някъде в моторния кош. Може и да бъркам.

Разбира се ако имате газова уредба, аларма, централно заключване и подобни екстри, то “народното творчество” на електричарите/газаджиите най-вероятно е влязло в действие. Те рядко имат практика да ви оставят листче със списък на направените промени. Така например е и при мен, като освен газова уредба и аларма имам и допълнителни перки за охлаждане (които не са вързани към допълнителното бушонно табло на 21214, защото при мен такова няма). Съвсем стандартно можете да намерите и разни бушонни гнезда из моторния кош. В такива случаи няма какво друго да направите освен да се ориентирате на място…

Възможни проблеми: Противно на очакванията най-честия проблем не е свързан с изгарянето на бушон, ами с липсата на контакт с бушона в таблото. Досега това ми се е случвало само с предните фарове, като по-точно с късите светлини. Наивна грешка на всеки начинаещ шофьор е, че ако единия фар спре да работи, то трябва да се смени крушката. Крушките на фаровете на Лада Нива почти никога не горят. До тях по принцип достига по-слаб ток от максималния допустим, което пък ги кара да светят малко по-слабо отколкото на другите коли, но за сметка на това, както споменах, много рядко изгарят.

Решението на споменатия проблем е тривиално – вадите бушона и го слагате обратно в гнездото му. Ако не сте взели необходимите предпазни мерки (виж “ВАЖНО” по-долу), то в този момент бушона може да изгори (с искри, които може да ви уплашат).

Гнездото на бушона впрочем е по-дълбоко, отколкото изглежда, че е. То си има гнезда, където бушона да “хлътне” (“щракне” или както искате го наречете). Иначе бушона може спокойно да бъде сложен (при това да дава контакт) и без да е вмъкнат правилно в гнездото. Тогава обаче ще има доста по-малка контактна повърхност и това е един от честите случаи, при които в последствие спира да дава контакт. Проверявайте си бушоните всеки път, след като някой “майстор” е поправял колата ви в сервиз. Съвсем възможно е да не са сложени както трябва.

ВАЖНО: Преди да сменяте бушони или да правите каквито и да е промени по бушонното табло, винаги откачайте клемите на акумулатора (или използвайте ключ-маса ако имате такава)! Използването на монета от пет стотинки вместо бушон е възможно за аварийни ситуации (ако нямате резервен бушон, но тогава защо нямате?), но е силно НЕпрепоръчително, защото може да доведе до сериозен пожар! Затова НЕ използвайте монети вместо бушони – по-добре вземете бушон от други прибори (или от неизползваните гнезда). И да – по-добре винаги носете комплект резервни бушони.

Първо да успокоим (почти) всички потребители, че уязвимостта засяга само тези инсталации, които използват PHP като чист CGI или mod_cgid модул. Ако използвате PHP като Apache модул (най-често срещаното), FastCGI или suPHP, то уязвимостта не ви засяга.

В какво се състои проблемът? Както пише в новината на сайта php.net, при “някои CGI инсталации на PHP” може да подавате командни параметри директно към php приложението ако в query string не присъства знакът “=”. Това всъщност е описано в RFC на CGI, но очевидно през 2004г. не е отчетено от разработчиците на PHP (докато например при Apache са го отбелязали много коректно) и така нещата продължават и до днес.

Един пример за възползване от уязвимостта е чрез отваряне на URL подобен на “http://www.yourwebsite.dom/phppage.php?-s” би се извикала команда “/<път до php>/php-cgi -s /<път до файла>/phppage.php”, което от своя страна ще отпечата сорс кода на файла директно в браузъра! Разбира се това е най-грубия възможен пример и почти най-опасния. За да видите с какви параметри можете да си “играете” пуснете “php -h” – повечето от тях може да се използват. Тази уязвимост най-общо позволява правенето на следните “поразии”:

• Чрез директно отпечатване на сорс кода на PHP файловете атакуващия може да открие парола за базата от данни, пътища до важни файлове, SALT кодове, да търси други налични пропуски в сигурността и т.н.;
• Ако атакуващият има възможност да качи php файл на сървъра, то може да го изпълни, а от там да получи достъп до много пикантни възможности – запис на файлове с phishing сайтове, качване на вирус в оригиналния сайт, подмяна на файлове за download, “хакване” на оригиналния сайт, изпращане на спам и т.н.;
• Да се направи напълно ефективна self-DoS атака (сървъра атакува самия себе си).

Предполагам, че има и по-засукани възможности, но тези са първите, които ми дойдоха на ум. Честно казано аз лично не съм виждал по-тежка и едновременно с това лесна за използване уязвимост, като изключим ерата на “ранния IIS”, където имаше няколко подобни истории.

Сега малко хронология:

На 13.01.2012г. хора от холандския сайт eindbazen.net (последвайте връзката, за да прочетете статията от първоизточника) откриват уязвимостта по време на конференция свързана с информационната сигурност.

На 17.01.2012г. написват e-mail до security@php.net с пълна информация относно проблема. По всяка вероятност никой не обръща внимание.

На 01.02.2012г. хората отново питат екипа на PHP по e-mail с въпрос “какво става”. Тогава получават отговор, че техния доклад е препратен “до когото трябва”. Вероятно точно тогава наистина са му обърнали (някакво) внимание.

На 23.02.2012г. разработчитите се свързват обратно и потвърждават наличието на уязвимостта.

… zzz …

На 05.04.2012г. хората от блога отново питат екипа на PHP “какво става бе хора?”. Получават отговор, че “ние от PHP работим по въпроса”.

На 20.04.2012г. хората от блога пак настояват за нещо повече по въпроса, като този път са “малко по-настоятелни”. Шест дни по-късно получават информация, че е подготвен “draft advisory”.

На 02.05.2012г. екипа на PHP им пише, че “в момента изпробват кръпка (patch) и искат малко повече време, преди да я пуснат в публичното пространство”.

На 03.05.2012г. някой в екипа на PHP прави фатална грешка - без да иска маркира въпросния bug report като “публичен”, т.е. видим от всички, при това без да е дадено дори временно решение. В китайски, руски и всякакви други форуми моментално се реагира и информацията изтича в публичното пространство. Веднага “плъзват” ботове, които правят опити за намиране на уязвими сайтове. Колко от намерените такива са хакнати остава отворен въпрос.

Още същия ден екипа на PHP реагира и изважда версии 5.3.12 и 5.4.2, които включват въпросния “patch, който все още се тества”, но промотиран като “работещ”. Оказва се, че тази кръпка никак НЕ работи, т.е. не работи както се очаква. Сайтовете работещи на PHP-CGI и mod_cgid все още продължават да са уязвими при определени условия (кръпката не отчита възможността за вмъкване на whitespace преди query string). Към момента (05.05.2012г.) единственото привидно правилно работещо решение е налично на eindbazen.net.

Използването на PHP като CGI модул (всеки скрипт се изпълнява като отделен процес) беше много популярно в миналото. Смяташе се, че това е по-сигурния начин да се изпълняват скриптовете (всъщност и до сега си има много адекватни аргументи, че това наистина е така въпреки, че с казаното по-горе нещата изглеждат трагично различни). С течение на времето все повече хостинг провайдъри започнаха да пускат инсталациите си като Apache модул, но все пак достатъчно много стари сървъри останаха на CGI режим. И достатъчно много нови. За щастие рядко във варианти като изказаните два – по-често се използва suPHP или FastCGI.

Ако все пак имате сайт на споделен хостинг сървър, който използва подобна уязвима инсталация, то едва ли имате достъп да слагате подобни “third party” кръпки. Разбира се, че администраторите биха решили проблема (ако са достатъчно отговорни) временно, докато излезе истински работещ официален patch. Ако обаче администраторите са безотговорни (а такива има много – университетски сървъри, които са зарязани някъде незнайно в коя зала; сървър в министерство, зарязан също незнайно къде и все такива подобни примери), то се намирате пред реално изпитание. Най-бързото работещо решение на проблема е следното – създайте .htaccess файл, който филтрира заявките с mod_rewrite по следния начин (взех го от коментарите в блога на eindbazen):

RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]

Обобщение: Е не очаквах точно от екипа на PHP подобни безобразия. Не толкова, че се е получил подобен “бъг”, а по-скоро за отношението към него.

Редакция 08.05.2011г. – от екипа на PHP извадиха нова версия 5.4.3, в която уязвимостта е премахната коректно.

База от данни

За тестова таблица ще използваме “city” от базата от данни “world” (примерна тестова база от данни в сайта на MySQL). В нея първичен ключ е колона “id”, в който стойностите са поредни (AUTO_INCREMENT) и БЕЗ ДУПКИ (няма изтрити стойности). Последното е важно, защото повечето от методите разчитат именно на това свойство, за да се възползват от допълнителна бързина. Целта ни е с една заявка да извлечем едно произволно име (колона name) от базата от данни. Някои от методите позволяват и повече.

Test 1: Класически метод

Този метод се споменава в документацията на MySQL. В него се прави следното:

SELECT name FROM city 
ORDER BY RAND() LIMIT 1;

Той създава по едно произволно число за всеки ред от таблицата и след това сортира редовете спрямо тези произволни числа. Правейки LIMIT 1 ние взимаме само първия ред от резултатната таблица. Ако искате повече, то просто увеличете числото.

Класическият метод работи без да има значение какви са стойностите в колоната id. Използва се индекс по колоната “name” и има “Using temporary; Using filesort”.

Test 2: Произволно id в WHERE

Методът е взаимстван от блога на Akinas. В тази заявка е много важно id да са поредни и “без дупки”. Първо се взима броя на редовете в таблицата (който се приема и за най-голямата стойност на id), след това се взима първото id, което е след тази стойност.

SELECT RAND()*COUNT(*) 
INTO @randid FROM city;

SELECT id, name FROM city 
WHERE id >= @randid
LIMIT 1;

С този метод НЕ можете да вземете повече от един произволен ред наведнъж. Също така е много важно броя на редовете в таблицата да отговаря на най-голямото id в нея, а също така разчита на равномерното разпределение на id-та (т.е. може да има “дупки”, но те също трябва да са равномерно разпределени).

Test 3: Произволно id в WHERE с непоредни числа

Методът отново е взаимстван от блога на Akinas. Този метод е абсолютно същия както предишния, но с тази разлика, че няма нужда по колоната “id” да имаме поредни стойности от 1 до N, а може да са в произволен интервал от A до B:

SELECT FLOOR(MIN(id)+ RAND()*(MAX(id)-MIN(id)+1)) 
INTO @randid FROM city;

SELECT name
FROM city
WHERE id >= @randid
LIMIT 1;

Както и в предишния метод – тук силно се разчита на добро равномерно разпределение на id-тата. Липсата на “дупки” между тях ще дава правилни резултати. Отново не можем да взимаме повече от един произволен ред наведнъж.

Test 4: ORDER BY RAND() с отрязване на част от таблицата

Този метод е предложен от Josh Hartman и се основава на намаляване на броя на редовете, които трябва да се сортират чрез ORDER BY RAND().

SELECT name FROM city 
WHERE RAND()<(SELECT ((1/COUNT(*))*10) FROM city) 
ORDER BY RAND() 
LIMIT 1;

Както се вижда от кода – в WHERE клаузата се взима произволно число, което се проверява дали е по-малко от дадена референтна стойност. Числото 1/count(*) е умножено по 10, за да не стане референтната стойност прекалено малка, което да създаде по-голям риск от “пропускане” (вижте забележката след параграфа). Ако искате да се върнат N реда, то трябва да направите “…(N/COUNT(*))*10…” и “…LIMIT N”. Накрая се извършва “ORDER BY RAND()”, за да не се дава предимство на по-малките id-та спрямо по-големите.

ВАЖНО: Този метод НЕ гарантира връщане на резултат! Винаги съществува възможност, макар и в случая минимална, RAND() да връща винаги стойности над референтната, с което накрая да се окаже, че не е върнат никакъв ред.

Test 5: JOIN метод

Това е класически начин за изваждане на произволен ред от таблица. Взима се оригиналната таблица и към нея по “id” се присъединява едно единствено произволно число, което е от 1 до максималното в таблицата city:

SELECT city.name
FROM city JOIN
     (SELECT CEIL(RAND() * (SELECT MAX(id) FROM city)) AS id) AS tmp
     ON city.id >= tmp.id
LIMIT 1;

Задължително в този метод е id-тата да са поредни започващи от 1 нататък и да няма “дупки” или поне да са равномерно разпределени. С този метод НЕ можете да вземете повече от един произволен ред накуп – увеличаването на стойността в LIMIT ще върне поредни редове, а не произволни!

Test 6: JOIN метод чрез използване на локална променлива

Предложен в MySQLDiary.com,  това е подобрение на предишния метод, тъй като позволява да взимаме повече от един произволен ред (увеличавайки стойността след LIMIT във вътрешната таблица):

SELECT city.name
FROM city JOIN
     (SELECT CEIL(RAND() * (SELECT MAX(id) FROM city)) AS num, @num:=@num+1 
      FROM (SELECT @num:=0) AS a, city LIMIT 1) AS tmp 
     ON tmp.num = city.id;

При така показания метод е задължително да НЯМА дупки.

Тест 7: OFFSET метод

Предложен от electrictoolbox.com. Методът се състои в следната последователност:

1. Намираме общия брой на редовете в таблицата и го записваме в променлива;
2. Генерираме произволно число и го умножаваме по общия брой редове от таблицата;
3. Извличаме ред от таблицата чрез LIMIT 1 и OFFSET намереното в т.2 число.

Първият проблем идва в това, че не можем да подаваме променливи в LIMIT. Затова се налага да използваме подготвени заявки:

SELECT FLOOR(RAND()*COUNT(*)) INTO @count 
FROM city;

PREPARE stmt 
FROM 'SELECT name INTO @temp FROM city LIMIT 1 OFFSET ?';

EXECUTE stmt USING @count;

При този метод имаме едно голямо предимство – за разлика от всички алтернативни на ORDER BY RAND() методи тук въобще НЕ зависим от колоната id, т.е. няма проблем да има “дупки” в нея. Недостатък е, че не може да извлича повече от един произволен ред в една заявка – налага се за n реда да изпълните n заявки (при ORDER BY RAND() не е така).

Тестова постановка

Създаваме 7 съхранени процедури, всяка от която съдържа по един от методите. Входния параметър на тази заявка е число, което има смисъла на “брой повторения”, които ще направим на метода:

DELIMITER //
CREATE PROCEDURE test1(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
      SELECT name INTO @temp FROM city 
      ORDER BY RAND() LIMIT 1;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test2(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
      SELECT RAND()*COUNT(*) INTO @randid FROM city;
	  SELECT name INTO @temp FROM city 
      WHERE id >= @randid
      LIMIT 1;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test3(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
      SELECT FLOOR(MIN(id)+ RAND()*(MAX(id)-MIN(id)+1)) INTO @randid 
      FROM city;
      SELECT name INTO @temp FROM city
      WHERE id >= @randid
      LIMIT 1;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test4(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
      SELECT name INTO @temp FROM city 
      WHERE RAND()<(SELECT ((1/COUNT(*))*10) FROM city) 
      ORDER BY RAND() 
      LIMIT 1;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test5(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
     SELECT city.name INTO @temp
     FROM city JOIN 
          (SELECT CEIL(RAND() * (SELECT MAX(id) FROM city)) AS id) AS tmp
	      ON city.id >= tmp.id
      LIMIT 1;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test6(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
     SELECT city.name INTO @temp
     FROM city JOIN
          (SELECT CEIL(RAND() * (SELECT MAX(id) FROM city)) AS num, 
                  @num:=@num+1 
           FROM (SELECT @num:=0) AS a, city LIMIT 1) AS tmp 
          ON tmp.num = city.id;
     ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

DELIMITER //
CREATE PROCEDURE test7(tests INT)
BEGIN
  label1: LOOP
    SET tests = tests - 1;
    IF tests > 0 THEN
      SELECT FLOOR(RAND()*COUNT(*)) INTO @count FROM city;
      PREPARE stmt 
      FROM 'SELECT name INTO @temp FROM city LIMIT 1 OFFSET ?';
      EXECUTE stmt USING @count;
      ITERATE label1;
    END IF;
    LEAVE label1;
  END LOOP label1;
END//
DELIMITER ;

Забележете, че при извикването на всяка заявка се прави “SELECT name INTO @temp”, за да записваме върнатия произволен ред в променлива, вместо да го връщаме към приложението като резултатна таблица. Освен това обърнете специално внимание на test7 – при него беше много по-подходящо да изместим “PREPARE stmt…” заявката извън тялото на цикъла. Нарочно това не е направено, за да не се дава предимство на метода спрямо останалите. Впрочем разликата не е значителна (в порядъка 2-3 секунди), но все пак така е правилно.

След това изпълняваме всяка една процедура два пъти, като между пусканията на всеки две различни процедури спираме MySQL сървъра (за да сме сигурни, че няма вътрешни оптимизации, които да променят резултата):

mysql> CALL test1(10000);
Query OK, 1 row affected (39.56 sec)

mysql> CALL test1(10000);
Query OK, 1 row affected (39.52 sec)

mysql> CALL test2(10000);
Query OK, 1 row affected (18.33 sec)

mysql> CALL test2(10000);
Query OK, 1 row affected (18.13 sec)

mysql> CALL test3(10000);
Query OK, 1 row affected (19.11 sec)

mysql> CALL test3(10000);
Query OK, 1 row affected (18.97 sec)

mysql> CALL test4(10000);
Query OK, 1 row affected (38.77 sec)

mysql> CALL test4(10000);
Query OK, 1 row affected (38.64 sec)

mysql> CALL test5(10000);
Query OK, 1 row affected (1.91 sec)

mysql> CALL test5(10000);
Query OK, 1 row affected (1.84 sec)

mysql> CALL test6(10000);
Query OK, 1 row affected (1.42 sec)

mysql> CALL test6(10000);
Query OK, 1 row affected (1.41 sec)

mysql> CALL test7(10000);
Query OK, 1 row affected (27.44 sec)

mysql> CALL test7(10000);
Query OK, 1 row affected (27.66 sec)

Ясно се вижда, че класическия метод (test1) и предложената модификация (test4) дават възможно най-лоши резултати. При това test4 не гарантира въобще, че ще се върне какъвто и да е резултат – затова директно можете да го отхвърлите като възможност.

Тестовете с произволно число в where (test2 и test3) стоят непосредствено след това, като са двойно по-бързи. Те от своя страна помежду си дават несъществена разлика в бързодействието. Това ни насочва към това да препоръчаме “по-сигурния” от тях – test3.

Абсолютните фаворити са JOIN методите (test5 и test6). При това втория, който дава по-добри възможности, дава и по-добри резултати.

Колкото до test7 – той определено се справя много по-добре от test1, при това няма недостатъците на останалите тестове. За жалост при него не е възможно да се извлече повече от един ред накуп в една заявка.

Извод

При напълно разнородни данни, т.е. такива без никаква подредба по идентификатор, използвайте класическия метод (test1) когато искате да изкарате множество редове накуп или методът с offset (test7) когато искате да изкарате един единствен произволен ред.

При напълно подредени стойности по колоната id – ако например тя е primary key с auto_increment и няма изтрити редове, то JOIN методите са в пъти по-бързи! При тях втория (test6) е за предпочитане, тъй като позволява връщане на повече от един произволен ред в една заявка.

Ако все пак има “дупки” в колоната “id”, но преценявате, че те са сравнително равномерно разпределени, то може да се възползвате и от методите с произволно число в where (test2 и test3). При тях по-добър, пък макар и минимално по-бавен, е test3. Отново напомням, та макар и с риск да стана досаден, че при едно извикване на заявката можете да взимате само един произволен ред, а не множество такива (това е сериозен недостатък ако ви трябват няколко произволни реда и в такъв случай обезсмисля метода).

Не използвайте test4, тъй като той е сбъркан по дизайн и неефективен по бързодействие.

Нека синтезираме казаното и да определим подходящите методи за взимане на :

• Подредни числа, без дупки: test6
• Равномерно разпределени числа, но с дупки и при нужда само от един произволен ред: test 5
• Без каквато и да е подредба или неравномерно разпределени числа и при нужда само от един произволен ред: test7
• Без каквато и да е подредба или неравномерно разпределени числа и при нужда от повече от един произволен ред: test1

П.П. Всички тестове са проведени при InnoDB таблица. Ако използвате MyISAM таблица, то всички методи, които използват COUNT(*) – тестове 2, 4 и 7 – ще работят по-бързо, понеже в MyISAM броят на редовете в таблиците се кешира.

Задача: Прехвърлете данните от таблица city в MyISAM хранилище и проведете същите тестове.

П.П.2. Последна редакция на 09.05.2012г.

Оригиналната нова предна броня за Лада Нива не е кой знае колко скъпа. В общи линии е на цената на “направи си сам”. Оригиналната броня е алуминиева и честно казано доста добра. Аз обаче реших да пристъпя към “тунинг”. Най-вече стана брагодарение на колегата Владимир Раденков (vladyas), който ме убеди, да пристъпя към тази стъпка.  Ето и резултата – Ладата вече се усмихва:

Захващането се прави на оригиналните буфери. Ъглите по краищата налагат леко рязане на решетката. Ето как изглежда отстрани:

Всъщност едно от слабите места на оригиналната броня е именно захващането – сравнително слабо е. Затова са сложени две допълнителни подпори. Важно е да не са много здрави, т.е. да могат при удар да се чупят първо те. Все пак не са хванати за рама защото Нивата е самоносеща конструкция:

Както се вижда от снимките по-горе – калниците са отрязани. Това поне помага да не се дерат в гумите при попадане в дупка – припомням, че съм с Ласа ОК 144, които са значително по-големи от оригиналните. Бронята следва тяхната линия. Така предницата придобива съвсем нов вид – много от “карантията” става видима:

Ето изглед на бронята отдолу:

… и отгоре:

Към това към ремонта се прибави още изправяне на геометрията, смяна и боядисване на маска (напълно изгнила + унищожена), изправяне и рязане на калник, изкърпване на дупки (изгнило) по задния калник… и т.н. Дали по принуда или не – такива моменти си идват рано или късно.

<?php
// В началото добавяме подзаглавието на сайта
$meta = get_bloginfo('description').': ';
// Проверява дали е страница или пост
if (is_singular()){
	// Намираме къде свършва първото изречение
	$pos = mb_strpos($post->post_content, ". ", 0, 'UTF-8');
	// Ако е намерено първо изречение, то го добавяме
	if($pos !==false)
	   $meta .= mb_substr($post->post_content, 0, $pos, 'UTF-8');
	// В противен случай взимаме целия пост
	else $meta .= $post->post_content;
}
elseif (is_category()){ // ако сме в категория с много статии
	// Добавяме описанието на категорията
	$meta .= category_description();
}
// Задължително премахваме всякакви HTML тагове
// и прекодираме кавичките и специалните символи
$meta = htmlentities(strip_tags($meta), ENT_QUOTES, 'UTF-8');
// Премахваме нови редове, табулации и празни интервали
// Поредици от празни интервали се получават често, когато
// имате много къс първи параграф в който няма точка.
$meta = str_replace(array("\n","\r","\t",'   ','  '),' ', $meta);
// Ако meta description е по-дълъг от 255, то го скъсяваме
if(mb_strlen($meta)>=255) $meta = mb_substr($meta, 0, 254);
// Отпечатваме мета тага
echo "<meta name='description' content='{$meta}' />\n";
?>

Предполагам, че може да се поправи и да стане доста по-прилично. Направих редица тестове и изглежда, че се справя добре с UTF-8 кодировка. За 404 и страници генерирани от търсене не се слага meta description. Ако някой забележи грешки или намери начин за оптимизация, нека сподели.

Някои по-нататъшни насоки:

• Винаги започвайте статиите си с описателно първо изречение, като по възможност включвайте важната ключова дума;
• Избягвайте да започвате с параграф с едно единствено изречение;
• Стремете се първото ви изречение да е в рамките на 150 символа.

Колкото до мета тага за ключови думи (meta keywords) – там нещата са доста по-сложни. Автоматизираното разпознаване на добри ключови думи не е толкова проста работа. По-нататък евентуално ще завърша скрипт и за това.

Какво ново във версия 2.0? На първо място вече се поддържа не само LateX и MathML, но и AsciiMath! Това вече наистина го направи незаменим лидер сред софтуера за писане на математически формули в уеб сайтове, защото практически вече поддържа всички възможни стандарти. При това резултата се изобразява в браузъра в текстови вид, а не като картинка, което спомага да имаме индексиране от търсачките и поддръжка на copy/paste с други локални текстови редактори. Накрая, но не последно, формулите се изобразяват значително по-бързо спрямо предишната версия (всъщност MathJax беше най-бавната технология от тези, които разгледах).

Ето един пример за формула написана с MathJax 2.0 с режим displayMath:

[math]\sin{x} \cos{y} = \frac{1}{2}\left[ \sin{(x-y)}+\sin{(x+y)} \right][/math]

… и с режим inlineMath: [mathi]\sin{x} \cos{y} = \frac{1}{2}\left[ \sin{(x-y)}+\sin{(x+y)} \right][/mathi]

Ако виждате формулата от резултата, натиснете с десен бутон, за да видите допълнителни “екстри”. Може да правите “zoom” (при това доста удобен) и също така можете да копирате формулата в TeX или MathML формат. Също така ви се дава възможност да изобразявате с html/css, mathml или svg.

Освен това MathJax се инсталира буквално елементарно. Свалете последната версия от уебсайта и я разархивирайте в поддиректория “mathjax” в root директорията на вашия домейн (внимание – файловете са доста). След това вмъкнете следния код в <head> частта на вашите страници, в които искате да имате визуализиране на формули:

<script type='text/x-mathjax-config'> MathJax.Hub.Config({tex2jax: {inlineMath: [['[mathi]','[/mathi]']], displayMath: [['[math]','[/math]']]}})</script>
<script type='text/javascript' src='http://www.cphpvb.net/mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML'></script>

Разбира се вместо “cphpvb.net” сложете вашия собствен домейн. От тук нататък всеки текст, който е ограден с [mathi] и [/mathi] или [math] и [/math] ще се визуализира чрез MathJax скрипта (освен ако тези “BB кодове” не са вътре в тагове <pre> или <code>).

Конкретно за WordPress – ако искате да зареждате скрипта само когато е използван, а не на всяка страница, то може да използвате следния код:

$math_shortcode_found = false;
foreach ($posts as $post) {
   if (strpos($post->post_content, '[math')!==false){
      $math_shortcode_found = true;
      break;
   }
}
if ($math_shortcode_found) {
   echo ... // тук отпечатвате script таговете
}

Това ще облекчи изпращането на ненужни данни към потребителя (към момента 14690 байта) когато не се използват формули в дадена статия, но за сметка на това ще натовари сървъра (при всеки преглед на всяка статия ще се прави проверка за наличието на тага). По-добро решение е да слагате паразитен таг [mathi][/mathi] в началото на всяка статия, в която ще използвате математически формули и в PHP кода да сравнявате само началото на статията:

$math_shortcode_found = false;
foreach ($posts as $post) {
   if (strncmp($post->post_content, '[mathi][/mathi]', 15) == 0){
      $math_shortcode_found = true;
      break;
   }
}
if ($math_shortcode_found) {
   echo ... // тук отпечатвате script таговете
}

Празният таг е inline и няма да направи нов ред, а съдържанието му също е празно, затова mathjax няма да изобрази нищо. Неудобството е, че трябва да пишете този празен таг във всяка статия, в която ви трябва математическа формула. По-лошото обаче е, че този паразитен празен таг ще се показва във вашия RSS feed, както и евентуално може да повлияе на търсачките. Затова най-добре ще е да го добавяме в края на текста на статиите ни:

$math_shortcode_found = false;
foreach ($posts as $post) {
   if(mb_strlen($post->post_content)>15 &&
      substr_compare($post->post_content, '[mathi][/mathi]', -15, 15) === 0
     ){
      $math_shortcode_found = true;
      break;
   }
}
if ($math_shortcode_found) {
   echo ... // тук отпечатвате script таговете
}

MathJax 2.0 наистина е най-добрия софтуер за математически формули в уеб, който е излизал до този момент. Моят дневник вече официално е:

[mathi][/mathi]

… тази вечер отидохме на черква и вече можем да си кажем официално – ХРИСТОС ВОСКРЕСЕ!

Свещичките от снимката си ги донесохме от там и си ги запазихме по пътя до вкъщи запалени. А червеното яйце от миналата година се оказа здраво. Едно суеверие казва, че това било на щастие:

Общи настройки, променливи и формули

Четирите най-основни настройки за кеша на заявки са:

• Тип на кеша (query_cache_type): приема стойности 0 (изключен), 1 (постоянно включен) и 2 (работи “до поискване”);
• Размер (query_cache_size): колко памет да бъде отделена за кеша;
• Максимален размер на резултат от заявка (query_cache_limit): какво количество информация да отделяме максимално за всяка една заявка;
• Минимален размер на резултат от заявка (query_cache_min_res_unit): кеширането на прекалено малки резултати от заявки може да покаже по-лоши резултати, отколкото липсата на кеширане въобще.

И четирите променливи се задават чрез конфигурационния файл my.cnf. Може да видите текущите настройки от самата среда чрез следната команда:

mysql> SHOW VARIABLES LIKE 'query%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_alloc_block_size       | 8192     |
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 67108864 |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
| query_prealloc_size          | 8192     |
+------------------------------+----------+
7 rows in set (0.00 sec)

Преди да започнем с оптимизацията на кеша е много важно да отбележим изключително важна променлива – query_cache_wlock_invalidate. Ако тя е изключена (както е в примера, а това е и стойността по подразбиране) и използвате MyISAM, то SELECT заявки подадени към кеша ще се изпълнят успешно дори ако таблицата е заключена! Разбира се това в общия случай не е опасно, защото ако вие искате строга защита на данните, то тъй или иначе ще използвате InnoDB и ще се възползвате от транзакции.

Относно оптимизацията на кеша – за нас важна информация (след като системата е работила известно време в работен режим) е как точно се използва той:

mysql> SHOW STATUS LIKE 'Qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 5333     |
| Qcache_free_memory      | 21925712 |
| Qcache_hits             | 1334956  |
| Qcache_inserts          | 390420   |
| Qcache_lowmem_prunes    | 227914   |
| Qcache_not_cached       | 64768    |
| Qcache_queries_in_cache | 19173    |
| Qcache_total_blocks     | 44897    |
+-------------------------+----------+
8 rows in set (0.00 sec)

Основните неща, които трябва регулярно да изчисляваме  са три:

1. За текущо запълване на кеша използвайте следната формула (заета памет разделено на заделена памет):

((query_cache_size – Qcache_free_memory) / query_cache_size )*100

От нашия пример имаме запълване от 67%. Разбира се, че колкото по-плътно е запълването, толкова по-добре използваме заделената памет.

2. Ефективност на кеша се измерва като “процент от заявките, които се възползват от кеша”. Колкото повече заявки се възползват от кеша, толкова по-добре. Формулата за това идва от отношението между съвпаденията в кеша и общите заявки за търсене в кеша:

(Qcache_hits / (Qcache_hits+Qcache_inserts+Qcache_not_cached) )*100

От показания пример стойността е близо до 75%.

3. Честотата на използване на заявки от кеша се получава като отношението между  общите заявки към кеша и броят на вмъкнатите нови резултати от заявки в него, или:

Qcache_hits / Qcache_inserts

В примера честотата е приблизително 3,42. Колкото по-голямо е това число, толкова по-добре.

Какво се кешира?

Първото нещо, което трябва да знаете е, че се кешират само цели заявки. Вложени заявки, части от обединения и изгледи НЕ се кешират. Освен това резултатите в кеша се влияят от малки и главни букви и всякакви минимални разлики в кода на заявката! Например заявките “select * from users” и “Select * from users” за query cache се третират като различни. Същото важи за интервали, нови редове, коментари и всякакви други козметични разлики. Ето ви една основателна причина да спазвате стриктна конвенция при писането на SQL заявки.

Друго важно нещо е, че кеша работи с блокове памет. С други думи той чете директно входящия трафик на подадените заявки и започва да търси за съвпадение още с първите получени байтове и не изчаква заявката да бъде получена цяла. Това означава, че кеша работи на ниво още преди заявката да е компилирана, което впрочем обяснява и казаното горе за разликите между малки и главни букви на иначе идентични заявки.

Кешират се само и единствено SELECT заявки (динамични) и подготвени/параметризирани SELECT заявки (след MySQL 5.1). Извикването на съхранени процедури НЕ се кешира. Не се кешират и заявки, които използват локални или глобални променливи. Също така кешът НЯМА да работи ако са използвани функции като RAND(), NOW(), CURDATE(), CURTIME(), FOUND_ROWS() и т.н., т.е. функции които поради външни фактори могат да предизвикат различен резултат при едно и също извикване. Няма да се кешират заявки, които използват временни таблици (temporarily tables) и заявки, които генерират “предупреждения” (warnings).

При промяна на таблица (изпълнение на insert, update или delete заявка върху нея) се премахват от кеша всички заявки, които зависят от нея! Това означава, че е много неподходящо да използвате кеш ако таблиците, които използвате, много често се обновяват.

Фрагментация

Данните в кеша за заявки се записват в т.нар. “блокове”, които са с променлива дължина. В началото (при празен кеш) има един голям свободен блок. Когато се запишат данни в кеша блока се разделя на две, данните се записват в първия и след като се запишат (кеша за заявки не знае размера на резултатната таблица по време на записа) се освобождава незаетото пространство от текущия блок (т.е. прави се “trim”). Същото се повтаря нататък за останалия свободен блок. Така първоначално кеша ще се запълва равномерно.

С течение на времето обаче някои заявки ще се премахват от кеша, т.е. техните блокове ще бъдат освобождавани. По този начин остават “дупки” от празни блокове. Това се нарича “фрагментация” на блоковото пространство на кеша. Постъпващите нови резултати започват да търсят свободно място именно сред тези свободни блокове и започват да ги запълват поред. Когато резултатната таблица от нова заявка е по-голяма като размер от блока, в който иска да се запише, то MySQL ще потърси нов по-голям блок и ще премести текущо записаните данни в него. Това разбира се води до проблеми с производителността. В най-лошия случай блоковото пространство ще е силно фрагментирано и ще се отнемат много ресурси за преместване на информация от един блок в друг.

Един от начините да забележите, че вашето блоково пространство е фрагментирано е да наблюдавате променливата Qcache_lowmem_prunes. Тази променлива показва колко заявки са били “изхвърлени” от кеша, за да освободят блоково пространство за нови. MySQL премахва заявки от кеша на принципа “най-малко ползвана”. Ако стойността на тази променлива постоянно се увеличава, а в същото време имате много налична памет, то може с основание може да подозирате фрагментация.

Друг важен показател е отношението между Qcache_free_blocks и Qcache_total_blocks. Колкото по-близо е до 1/2 (което е най-лошия възможен случай), толкова по-зле е положението с разпределението на данните в кеша и обратно – колкото по-малко е числото, толкова по-малка фрагментация може да очаквате.

Фрагментацията на блоковото пространство може да се намали чрез оптимизиране на големината на минималната дължина на блок (променливата query_alloc_block_size). Увеличавайки стойността на тази променлива ще намали фрагментацията, но за сметка на това заявки с по-малки резултатни таблици ще изхабяват повече памет, отколкото им е била необходима. Един добър метод за груба настройка е да изчислите средната големина на резултат записан в кеша по следната формула:

(query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache

Ако вашата система е обаче е много разнородна, т.е. често има както големи, така и малки резултатни таблици, то оптимизацията на кеша срещу фрагментация ще е много трудна задача и намирането на оптимални стойности за блокова големина няма да бъдат толкова тривиални за намиране. В такива случай прочетете по-долу в графата “кеш до поискване”.

Дефрагментиране на кеша

Командата FLUSH QUERY CACHE дефрагментира блоковото пространство, като подрежда заетите блокове памет последователно от началото към края на заетата памет. По принцип операцията е бърза, но трябва да знаете, че по този начин целия кеш се “заключва”, а това практически “блокира” целия сървър – всички входящи връзки влизат в “спящ режим” докато кеша не се преподреди. Затова в никакъв случай не трябва да се прекалява с употребата на тази команда.

Ако искаме да автоматизираме процеса на дефрагментация, то можем да създадем събитие в системната таблица:

USE mysql

CREATE EVENT flush_query_cache
ON SCHEDULE EVERY 60 MINUTE
STARTS '2012-04-14 07:15:00'
DO FLUSH QUERY CACHE;

Разбира се трябва да сте включили изпълнението на събитията. Може да помислите и за по-сложна система за дефрагментация, като следите натоварването на сървъра и извършвате дефрагментацията на кеша и други оптимизационни дейности когато то е достатъчно ниско.

Оптимизиране на кеша спрямо начина за употреба

Пределно ясно за всички е, че колкото по-добре запълнен е един кеш, колкото колкото по-ефективен е и колкото по-голяма е честотата на заявките, толкова по-добре ще бъде употребен. Обратно – при ниска ефективност и малка честота на използване ние губим от наличието на кеш. Причината е, че този кеш също изисква ресурси за поддръжка. Затова е много важно да знаем как да го оптимизираме.

В началото трябва да отбележим, че много хора погрешно увеличават размера на кеша до много големи размери. Категорично трябва да отбележим, че в общия случай по-големия кеш НЕ означава по-добре работеща система. Напротив – ще забележите, че увеличаването на кеша от един момент нататък не помага на бързодействието на системата, а в някои случаи води дори до забавяне.

Преди да направите първите настройки трябва да прецените какъв тип приложения ще работят със системата. Ако например преобладават “малки заявки” (връщащи малки като обем резултатни таблици), а “големите” са малко на брой и не се използват често, то може да настроите ниски стойности на query_cache_min_res_unit и query_cache_limit – така ще кеширате презимно “малките” заявки, а ще отхвърляте “големите”. Обратно – ако приложенията ви ще правят чести заявки с големи резултатни таблици (разбира се повтарящи се такива!), то може да се лишите от кеша за “малките заявки” като увеличите query_cache_min_res_unit и сложите достатъчно голям query_cache_limit. При “разнородни” заявки към СУБД, т.е. честия случай, в който една система се използва за много различни приложения и различни бази от данни, то по-скоро направете диапазона широк (по-ниска стойност за query_cache_min_res_unit и по-висока за query_cache_limit) въпреки очаквано по-голямата фрагментация. Накрая ако приложението ви рядко прави еднотипни заявки и повечето заявки към базата от данни връщат различни резултати (напр. многопотребителска система, в която всеки потребител изисква свое собствено съдържание и то с редки потворения), то вероятно ще бъде по-добре ако напълно се лишите от кеша за заявки и го изключите.

Друго нещо, за което може да помислите е да организирате приложението си да прави “отложени промени”. Това означава да изпълнявате delete, update и/или insert заявки на “накуп” през зададени интервали от време, а не непосредствено след подаването им. По този начин вие съществено ще съкратите изхвърлянето на заявки от кеша и ще подобрите бързодействието им. От друга страна обаче това означава, че е възможно да позволите на потребителите си да прочетат “стара информация” от кеша. Затова използвайте този метод само при обновявания на таблиците, които не са задължителни “на момента” за правилната работа на системата. Също така имайте в предвид, че по този начин се носи и съответен риск при срив на уеб сървъра да се изгуби информация, която иначе е потвърдена на потребителя, че е записана.

Използване на кеш до поискване

Когато не споделяме СУБД с други потребители, а го използваме и настройваме самостоятелно, то със сигурност можем да спечелим изключително много от използването на “режим на кеш до поискване”. В този режим една заявка ще бъде записана в кеша само тогава, когато ние специално укажем, че това трябва да стане. За целта се добавя специален атрибут “SQL_CACHE” непосредствено след команда SELECT. Например ако ще се изпълнява заявка за изкарване на най-новите 10 статии на първа страница на даден сайт, то очакваме много потребители да четат тези данни и то множество пъти. Ако кеша е в режим “до поискване”, то можем да укажем, че искаме заявката да попадне в него по следния начин:

SELECT SQL_CACHE id, title, author
FROM articles 
ORDER BY date DESC
LIMIT 10;

Обратно – ако не желаем дадена заявка да попада в кеша, то можем да направим следната заявка с параметър SQL_NO_CACHE:

SELECT SQL_NO_CACHE last_login_time
FROM users
WHERE user = "ivan";

За улеснение може да приемете, че при query_cache_type = 1 всяка заявка ще бъде с атрибут “SQL_CACHE” по подразбиране, а при query_cache_type = 2 ще бъде с атрибут “SQL_NO_CACHE” по подразбиране. Виждате, че можете съвсем спокойно да се възползвате от тази тактика независимо в какъв режим се работи.

Използването на тази техникани позвовява да направим изключително ефективна система, която се възползва от кеша за заявки максимално добре. При правилен подбор на това “кои заявки да се кешират и кои не” ние можем да минимизираме фрагментацията, да увеличим ефективността и да се възползваме максимално добре от заделената памет. Създаването на една такава максимално ефективна система включва в себе си много прецизно планиране на всяко едно действие в нея.

Заключение

Като финал ще направим следното предупреждение, което може да се използва като основно правило за администраторите: лошо работещия кеш за заявки носи много повече вреда за производителността отколкото напълно изключения кеш за заявки. Ако винаги имате това наум и взимате необходимите мерки, то би трябвало вашия сървър да работи добре.

Преди почти две години написах една статия със заглавие “Привет на чалгата в науката“. В нея изказах някои от моите лични опасения относно подготвяната реформа в науката и образованието. Първата част от тази реформа отдавна вече е факт – “Закон за развитие на академичния състав” функционира пълноценно от месец април 2011г., т.е. вече измина една година откакто беше приет. Някои неща се случиха така, както си мислих, че ще станат, други не (за някои точки определено съм грешал). Време е за равносметка… Относно друга част на реформата, а именно “рейтинг на висшите учебни заведения” засега няма да си давам мнението.

Резултат №1: масова хабилитация на професори

Създаде се лавина от конкурси за хабилитиране в длъжност “професор”. Това беше ясно за всички в университетските и научните среди, но много малко хора имаха изгода да го повдигнат на дневен ред като проблем. Поради тази причина и въпросния проблем си назряваше тихомълком. Днес дори медиите се “самосезираха”: за последната година в България има нови 309 професори. Или казано по друг начин – удвоихме хабилитациите на професори в България. Причината е ясна за всички – отпадането на изискването професорите да са с научна степен “доктор на науките”, което явно преди е било голяма пречка.

Резултат №2: има реална опасност да се “раздават” докторски степени на асистенти

Това, което тепърва може да “избухне” като проблем е вързано с нуждата от спешен преход на много асистенти към длъжност “главен асистент”. Според ЗРАС и правилниците на университетите, длъжност “асистент” може да се заема максимум за четири години. През това време младият преподавател трябва едновременно да изпълнява норматива си за водени часове и да пише дисертационен труд, за да добие научна степен “доктор”, с която да може да кандидатства за “главен асистент”. За никой в момента не е тайна, че асистентската професия въобще не е популярна в България (средната възраст на преподавателите в университетите говори добре за това). За сметка на това университетите се стремят да приемат колкото се може повече студенти (за да получат по-голямо финансиране). Така, че асистентите в университетите освен притиснати от срока, в който трябва да станат доктори, се оказва, че в момента взимат и повече часове от нормалното (става въпрос по-скоро за популярните специалности). Това ще се промени в близко бъдеще, тъй като предстои поколение от период на демографски срив, но към текущия момент проблема е голям, особено за популярните специалности.

От казаното в предишния параграф не можем да кажем, че “привлекателността” на професията се е повишила, напротив – заплащането е същото както преди, а задълженията са се увеличили. Това разбира би трябвало да се отчете от ръковоствата в университетите и има опасност те да направят всичко възможно да задържат персонала си, та дори това да означава да се даде научна степен на човек, който не я заслужава. Това все пак е редно да се отбележи, че не е грешка на закона. Той сам по себе си е добър в частта си да изисква по-мотивирана работа от младите учени. Потенциалният проблем е следствие на наследената липса на престиж в длъжността “асистент” и силно занижения качествен контрол на научните трудове (за което ще говоря по-долу). Тоест реално може да се получи така, че в желанието си да се повишат изискванията за една длъжност ще се стигне до негативния ефект некачествени хора “да израстнат в кариерата през задната врата” и в крайна сметка да получим точно обратния ефект на заложения като философия в закона. Ако това се случи, то престижът на асистентската длъжност ще бъде уронен още повече и това по никакъв начин няма да спомогне за преодоляването на проблема “набиране на млади кадри в науката” в бъдеще.

Резултат №3: университетите (временно?) спряха да се интересуват от приемането на външни хора за научна степен “доктор”

Горе казах, че броят на професорите се е увеличил, но това се оказва, че не е съвсем вярно за научна степен “доктор”. Там даже се наблюдава обратното – силно понижение на броя на защитилите доктори. В предишните си статии по темата аз очаквах да има “лавина от докторски дисертации”. Оказа се, че дълбоко съм сгрешил в преценката си. Предполагам това се дължи на грешната ми лична оценка относно престижа на научно-образователната степен. Аз очаквах, че либерализирането на режима за придобиване на научни степени ще отприщи интерес от страна на завършващи студенти, а от друга страна в университетите ще се заформят корупционни практики за лесно придобиване на такива. Това не се случи. Напротив – университетите по-скоро се фокусираха върху собствения си персонал от асистенти и започнаха да пренебрегват външните. Може би няма достатъчно финансова изгода от развитие на докторантските програми, а може би проблемът е само моментен, защото персонала на университетите се съсредоточи върху своето собствено кариерно израстване и липсват време и ресурси за допълнително обслужване на докторанти. Признавам си – не знам…

Освен това по тази точка трябва да се отбележи, че вече има налични големи съмнения върху обективността на критериите при сравнение на дипломите на “вътрешни” и “външни” докторанти.

Резултат №4: деградиране на престижа на академичните длъжности

Пълната децентрализация на процеса на хабилитиране и процеса на оценка на дисертационните трудове от една страна се счита като голям позитив. От друга страна обаче пълната липса на какъвто и да е централен коректив довежда до силни противоречия в научните среди. От една страна научната степен “доктор” е валидна за цялата страна, а от друга всеки университет има свои собствени критерии за това как да се присъжда и за какво да се присъжда.

Всъщност проблемът при научна степен “доктор” е незначително по-малък в сравнение с тази при хабилитираните преподаватели, особено тези на длъжност “професор”. Традицията в българското общество е отредила едно престижно място на хората, които са достигнали това ниво в кариерата си. От друга страна този престиж вече е поднесен под съмнение. Наблюдават се явни задкулисни “борби” между “професорите от преди” и “новите професори”. Дори започва движение за създаване на неформални организации като “клуб на пълните професори”, т.е. “професори, които са с научна степен доктор на науките”. Подобно развитие очевидно ще доведе до явна деградация на духа в академичните среди и може да доведе до спадане на престижа на преподавателската професия, особено що се отнася до длъжността “професор”.

Резултат №5: напълно безконтролно оценяване на научни трудове

От една страна държавата гарантира дипломите за бакалавър, магистър, доктор и доктор на науките, но от друга има пълна липса на минимални държавни критерии за качество. Липсва какъвто и да е качествен контрол на национално ниво. Изискванията почти навсякъде са предимно количествени, но по никакъв начин не и качествени. Практически на много места се оказва така, че е възможно да се отчитат бройки на публикации без да се взима под внимание тяхното съдържание.

Освен това няма какъвто и да е ред за приемане на жалби от хора, които по един или друг начин са били в конфликт с учебните заведения, в които работят – получава се така, че ощетените могат да се оплачат само пред хората, които са ги ощетили. Не наричаше ли някой тази практика “феодални старци”? Не стана ли положението с обективността на оценяването на научните трудове още по-тежко спрямо предишното (а философията на закона трябваше да търси точно обратното)?

Резултат №6: предстоящ хаос поради неотчитане на демографските процеси

Това, че университетите отпушиха хабилитационните си програми и разрешиха ТЕКУЩИЯ си проблем с незаетите бройки от една страна е добре. За съжаление го правят на принципа “а след нас потоп”. Само след две години започва да добива пълнолетие поколението от 1996 година, а именно тогава започва и една сравнително дълга поредица от години, в които броят на студентите стремително ще намалее. Именно в този период от време очаквайте да станем свидетели на големи “борби за часове” в доста от по-непопулярните специалности в университетите, където преподавателите няма да могат да си изпълняват нормативите. Те всъщност и сега ги има, но положението все пак е “закърпено” на този етап.

Затова Либерализацията на заемането на длъжностите от една страна е нещо много добро, но пълната абдикация на централния орган от друга е нещо много лошо. Отново няма баланс между интересите на университетите и интересите на държавата. Не беше ли по-мъдро да се инвестира в млади кадри, вместо да се наливат безумно големи пари в развитието на стари (повечето от които скоро ще са в процес на пенсиониране)? Казвам това не за да кажа нещо лошо за по-възрастните ми колеги – за тях смятам, че в по-голямата си част заслужават много повече, отколкото получават. Казвам го, защото реалността наистина е такава – бедни сме и трябва да се разпростираме според чергата си.

Впрочем за случващото се у нас имаме много пресен пример от Румъния. Нашата съседка преди нас либерализира и децентрализара присъждането на научни степени и звания. Малко след като ние приехме нашия закон (който е направен по пълно подобие на техния), в Румъния беше приет нов закон, който прекрати либерализацията на научните степени и звания и спешно спря лавината от присъдждани звания и степени. При това там създадоха не един, а два нови контролни органа – “Национална комисия за атестация на кадрите и на дипломите” (изготвящ критериите за оценка на дипломи) и “Национален съвет за научните изследвания” (общо казано “изпитна комисия”).

Дали реформата в Румъния е била погрешна, а ние сме я направили по-добре от тях не се наемам да кажа. От всичко, което виждам в момента обаче мога да твърдя, че румънците вече се връщат от пътя, по който ние в момента вървим. И не са доволни от него…

Впрочем към момента в България вече Софийски Университет и Шуменски университет са въвели частични мораториуми върху хабилитациите на преподаватели в тях. При тях проблемът обаче не е, че отчитат някакви демографски процеси, а е чисто финансов – броят на хабилитациите при тях е надскочил бюджетите на учебните заведения. При всички случаи обаче процесът на румънския опит започва да се проявява и при нас.

Резултат №7: неясни критерии за назначаване на научните журита

В закона е записано ясно, че научните журита се състоят от две части – хабилитирани преподаватели от самия университет и външни преподаватели от други университети. Това разбира се са едни много добри намерения. От тук нататък обаче всичко е оставено “на произвола на съдбата”:

• Няма никаква прозрачност при назначаването на хора в научни журита;
• Формират се групи със съответни “сфери на влияние”.

Или казано по-простичко едни университети помагат на кадрите на други, в замяна другите правят същото обратно за първите. Освен това по този начин ръководствата на университетите добиват огромен контрол над научното развитие на персонала си (което напомням по философията на закона трябва да е отделно от длъжностното). Реално начинът, по който се назначава едно научно жури може да определи дали оценявания човек ще получи или няма да получи положителна оценка. При това, както споменах по-горе, няма адекватна възможност за протестиране. Това разбира се води само до едно единствено нещо: формиране на групи от т.нар. “феодални старци”, но този път на още по-лошото – местно ниво.

Резултат №8: законът НЕ доведе до увеличаване на младите учени

А това уж всъщност беше основната му цел – да насърчи младите хора. Всъщност се получи точно обратното. Няма какво да се лъжем – младите хора досега ставаха асистенти главно заради лекия режим на работа, който им позволяваше да работят паралелно по странични проекти, при това рядко научни. Те по никакъв начин не бяха и все още не са мотивирани финансово. В момента “лекия режим” вече никак не е толкова лек (притиснати са от сроковете за защита на дисертация) и интереса естествено още повече намалява. В момента положението се крепи главно заради последиците от икономическата криза и нарастналата безработица. Ако икономиката се стабилизира, то не се съмнявайте, че кризата за намиране на млади научни кадри ще стане още по-тежка.

Аз смятам, че отсега нататък в университетите ще се засилва познатата ни тенденцията за наемане на “оборотни преподаватели”, т.е. млади хора, които стават асистенти за няколко години, но после напускат. Целите на такива хора също отдавна са ясни за всички – набор на персонал за частни фирми и/или натрупване на престиж в личната автобиография, който да им помогне при реализация в чужбина. Научната дейност при такива хора обикновено е сведена до минимум. Впрочем никой не може да гарантира, че наличните млади хора, работещи в сферата на науката и образованието в момента, няма да напуснат системата при евентуално стабилизиране на бизнес климата в страната. Даже на този етап аз силно ще бъда очуден ако това не се случи и текущите кадри се задържат при сегашните условия на труд…

Обобщен резултат: преподавателите и учените изместиха фокуса си от научната работа към бизнес интереси

Липсата на ясни минимални критерии за оценка на научни трудове в комбинация с огромното влияние на ръководствата на университетите над персонала, както и явната обезценка на научните степени и звания, водят до това, че преподавателите и учените все по-малко се интересуват от наука. За сметка на това за тях става все по-важен кариеризма, т.е. вписването в организацията на финансовите потоци. Казано по-простичко – ако направите голямо научно откритие, то не е гарантирано по никакъв начин, че въобще ще се издигнете, но ако успеете да се впишете в бизнес модела и да спомогнете за облагодетелстването на съответния “кръг на интереси”, то издигането ви е вързано в кърпа. Колкото до научните приноси на избралите втория начин – за израстването на един преподавател/учен в момента е важно “да има бройки публикации” и няма абсолютно никакво значение какво е тяхното качество. Преди поне то се съблюдаваше от ВАК, въпреки постоянните протести и масово неодобрение.

Не всичко е толкова лошо

Да се сатанизира всичко в настоящия закон и да се отхвърля цялата му философия ще бъде точно толкова погрешно, колкото отхвърлянето на всички стари наложени практики с ВАК, както направи самия той. Не е добре да се повтаря грешката на написания закон при работата по очевидната нужда от написване на нов такъв. Затова смятам за важно да се отбележат и положителните страни на проведената реформа:

• Първо трябва да кажа сериозно, че децентрализацията не е лошо нещо. Просто трябва да се направи “крачка назад” и да се намери баланс между държавния контрол и автономията. В никакъв случай не мога да бъда привърженик на обратно пълно централизиране на контрола (въпреки, че според мен ще води до по-добри резултати от сега постигнатите).
• Второ наложените по-строги изисквания за заемане на академични длъжности на ниските нива (асистент и главен асистент) са нещо много добро. Със сигурност трябва да бъде запазено, но и последвано от още допълнителни мерки. На първо време трябва спешно да се помисли за въвеждането на стимули за трайно задържане на млади хора в сферата на науката и образованието (със сигурност на първо място финансови). Освен това трябва да се промени философията на кариерното развитие – младите хора трябва да се фокусират върху иновациите и научните открития, а не към други обслужващи финансовите потоци дейности.
• Обособяването на научни журита е добра практика. Просто трябва да бъде изгладен начина на тяхното формиране и да бъде контролирано тяхното функциониране.
• Въведеното уеднаквяване на академичните длъжности между научните организации и университетите е силно позитивно за системата. Посоката, в която трябва да се продължи е да станат и еднакви по качество, а не само на хартия.

Надявам се, че следващото правителство ще прояви желание да поправи белите и да осъществи тези неща. За текущото вече няма време, а няма и признаци за желание. За съжаление отново загубихме четири ценни години като управляващите отричаха, чупиха и продаваха вече съграденото, а не успяваха да изградят ново, което да е по-хубаво.

Подготвените заявки могат да бъдат с и без параметри. Ето един пример за такава заявка без параметри:

mysql> USE world;
Database changed
mysql> PREPARE citycount FROM
    -> 'SELECT COUNT(*) FROM city';
Query OK, 0 rows affected (0.00 sec)
Statement prepared

В горния пример ние подготвихме заявката ‘SELECT COUNT(*) FROM city’ за изпълнение. В последствие можем да я изпълним по следния начин:

mysql> EXECUTE citycount;
+----------+
| COUNT(*) |
+----------+
|     4079 |
+----------+
1 row in set (0.00 sec)

“Параметризирани” са тези подготвени заявки, които не са просто статично зададени, а на които им подаваме различни параметри, според които можем да имаме различен резултат. Например ако искаме не просто броя на всичките градове в системата, а градовете от определена държава, то можем да подготвим заявката по следния начин:

mysql> PREPARE citycount_by_country_code FROM
    -> 'SELECT COUNT(*) FROM city WHERE CountryCode = ?';
Query OK, 0 rows affected (0.30 sec)
Statement prepared

Обърнете внимание на въпросителния знак – той указва мястото, където ще бъде “вмъкнат” параметъра в последствие. Ето как правим това:

mysql> SET @ccode = 'BGR';
Query OK, 0 rows affected (0.00 sec)

mysql> EXECUTE citycount_by_country_code USING @ccode;
+----------+
| COUNT(*) |
+----------+
|       10 |
+----------+
1 row in set (0.00 sec)

mysql> SET @ccode = 'GBR';
Query OK, 0 rows affected (0.00 sec)

mysql> EXECUTE citycount_by_country_code USING @ccode;
+----------+
| COUNT(*) |
+----------+
|       81 |
+----------+
1 row in set (0.00 sec)

Разбира се параметрите може да са повече от един, като единственото което трябва да съблюдаваме е техния ред:

mysql> PREPARE citycount_by_code_and_district FROM
    -> 'SELECT COUNT(*) FROM city
    '>  WHERE CountryCode = ? AND District = ?';
Query OK, 0 rows affected (0.00 sec)
Statement prepared

mysql> SET @ccode = 'BGR';
Query OK, 0 rows affected (0.00 sec)

mysql> SET @district = "Plovdiv";
Query OK, 0 rows affected (0.00 sec)

mysql> EXECUTE citycount_by_code_and_district
    -> USING @ccode, @district;
+----------+
| COUNT(*) |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

След като спрем да ги използваме е нужно да “почистим”, т.е. да освободим паметта от подготвените/параметризираните заявки, които сме направили. Това се прави чрез командата DEALLOCATE:

mysql> mysql> DEALLOCATE PREPARE citycount;
Query OK, 0 rows affected (0.00 sec)

mysql> DEALLOCATE PREPARE citycount_by_code
Query OK, 0 rows affected (0.00 sec)

mysql> DEALLOCATE PREPARE citycount_by_code_and_district;
Query OK, 0 rows affected (0.00 sec)

Освен това е редно да споменем, че параметризирани заявки могат да се правят и върху INSERT/UPDATE/DELETE, както и върху множество други оператори, а не само върху SELECT.

Какво печелим от подготвените заявки без параметри? Идеята за тях се свежда до това да направим подготовката на заявката само веднъж, а след това да я изпълняваме множество пъти. Ако трябва да изпълняваме множество от едни и същи динамични заявки, то за всяка една от тях ще имаме процес на подготвяне и изпълнение, т.е. при N заявки ще имаме N подготовки, а иначе ще имаме само една. Все пак имайте и в предвид това, че за нуждите на еднократно изпълнение на заявка подготвените заявки са по-бавни от динамичните.  Причината е, че се заделят допълнителни ресурси за поддържане на “дървото на изпълнение” на компилираната заявка. Тоест ние бихме спечелили от подготвени заявки без параметри само тогава, когато изпълняваме заявките много пъти в една сесия.

В общия случай обаче от подготвените заявки без параметри не се печели почти нищо, защото както подготвените, така и обикновените динамични заявки ще се възползват от query_cache, а кешът  тъй или иначе е най-бързия възможен начин за връщане на резултат от заявките. Тоест от подготвените заявки без параметър печелим тогава, когато се налага да изпълняваме заявките много поредни пъти и НЕ се използва query_cache. Като частична полза може да се каже това, че при повторни изпълнения на заявката към сървъра се подава само низ “EXECUTE <име-на-заявка>”, а не целия текст на SQL заявката (което може да ви спести малко количество мрежови трафик за всяка заявка).

Що се отнася до параметризираните заявки – там вече предимството на подготвената заявка се проявава в повече практически ситуации. Предимствата основно са три:

• Ако трябва да изпълните една и съща заявка много пъти и с различни параметри, то параметризираните заявки ще имат значително по-голямо бързодействие спрямо динамичните;
• При многократно изпълнение се намалява мрежовия трафик (вече го споменахме в предишния параграф), макар и незначително;
• Предотвратява възможностите за атаки от тип “SQL Injection”, понеже логиката на заявките вече е предварително зададена и няма начин да бъде променена по време на изпълнение. Все пак внимавайте – това, че сме защитени от такива атаки не означава, че “сме си свършили работата”. Много по-добре е въобще да НЕ се изпълнява SQL заявка при въведени невалидни данни, отколкото да се изпълнява такава, което очевидно ще изхаби ресурси, а резултатът от нея (би трябвало да) е предварително известен (тоест безсмислено търсен). Валидирането на коректността на данните като правило е добре на първо място да е задача на приложението (при това извършено непосредствено след получаването им) и в никакъв случай НЕ трябва отговорността за това да се прехвърля напълно върху системата за съхранението им.

Ако параметризирана заявка се изпълнява еднократно или множество пъти, но с едни и същи параметри, то предимството от първата точка в общия случай се изгубва по същия начин, както в параметризираните заявки без параметри – в тези случаи с предимство ще се стремим да се възползваме от кеша на заявките (query cache).

Сега остава да дискутираме и начините за практическа употреба на подготвени заявки в реално действащи приложения. Горният метод за изпълнение на подготвени заявки се нарича “SQL интерфейс”. С него софтуерните продукти работещи с MySQL база от данни подават заявките по същия начин, както го правят с динамичните заявки, а подготовката и изпълнението се правят изцяло от страната на СУБД.

Съществуват и други, значително по-добри начини за работа с подготвени заявки, например MySQL C API client library (за програми написани са езика за програмиране C), MySQL Connector/J (за приложения на Java) и MySQL Connector/Net (за ADO.Net). При традиционния протокол заявките се изпращат към MySQL като текстови низ, след което самата СУБД конвертира стойностите на параметрите до съответния тип данни. Споменатите интерфейси позволяват програмата да комуникира директно със СУБД като предава данните като бинарна поредица, като до голяма степен се запазват типовете на данните. По-важното в случаят е, че интерфейсите минимизират мрежовия трафик между програмата и СУБД и то този път значително – практически се предават само стойностите на параметрите, заедно с число-идентификатор на заявката, а не целия й текст (дори в SQL интерфейса трябваше да се подава думата “EXECUTE” и името на заявката като текстови низове, което е доста по-голямо количество информация спрямо едно обикновено число-идентификатор). Затова е препоръчително да се възползвате от средите за програмиране, които предлагат възможност за работа с такива интерфейси.

Например в PHP разширението mysqli.so (забележете, че в края на името има “i”, защото старото разширение mysql.so не се възползва от споменатия интерфейс) работи аналогично на C API client library (има почти пълно съответствие между двете). Ето примерен код за работа с параметризирани заявки в PHP:

// Свързваме се с базата от данни
$link = mysqli_connect('хост','име','парола','база от данни');
if(mysqli_connect_errno()){
	echo 'Проблем при връзката с базата от данни';
	exit;
}
// Заявката, която ще подготвим
$query = "SELECT COUNT(*) AS citiesN FROM city WHERE CountryCode = ?";
// Параметъра, който ще подадем
$ccode_param = "BGR";
// Инициализиране на инстанция за заявката
$statement = mysqli_stmt_init($link);
// Подготвяме заявката за изпълнение
if (mysqli_stmt_prepare($statement, $query)){
    // Подаваме параметъра към вече подготвената заявка
    // "s" означава "string", т.е. параметъра е текстови низ
    mysqli_stmt_bind_param($statement, "s", $ccode_param);
   // Изпълняваме заявката
   mysqli_stmt_execute($statement);
   // Ще записваме резултата от заявката в променлива $result
   mysqli_stmt_bind_result($statement, $result);
   // Взимаме резултата от изпълнението на заявката
   // Той ще бъде записан в $result
   mysqli_stmt_fetch($statement);
   // Отпечатваме резултата
   if(isset($result)) echo "Броят на градовете в $ccode_param e $result";
   else "Броят на градовете в $ccode_param e 0";
   // Затваряме интерфейса за параметризираната заявка
   mysqli_stmt_close($statement);
}
// Затваряме връзката с базата от данни
mysqli_close($link);

В горния пример разбира се ние изпълнихме заявката само веднъж, т.е. не се възползвахме от предимствата на подготвените заявки, а даже напротив – разходвахме (макар и минимално) допълнителни ресурси. Тук обаче е момента да отбележим нещо много важно: винаги затваряйте интерфейса за параметризираната заявка от момента, от който няма да я използвате повече  – от примера това става с извикването на функцията mysqli_stmt_close. Често срещана практика при програмистите е да забравят да затварят връзките си към базите от данни, което не е прекалено голям проблем, понеже стандартно те се затварят с края на изпълнението на PHP скрипта. При изпълнение на подготвени заявки обаче се поддържа отделна нишка с връзка към сървъра за всяка една параметризирана заявка, а ние казахме, че използваме подготвените заявки предимно тогава, когато ще ги изпълняваме многократно, т.е. очаква се скрипта да работи с големи обеми от информация и да отнема дълго време за изпълнение. Умножете броя на връзките за параметризирани заявки по броя на потребителите, които използват системата в един момент от време и ще видите, че ненужно поддържаните връзки към базата от данни могат да отнемат значително количество ресурси на СУБД, без да ги употребяват. В практиката често се среща претоварване на SQL сървър поради неправилно менажиране на подготвени заявки от страна на приложението, което работят с него.

Някои от интерфейсите, като например Connector/J и Connector/Net поддържат и подготовка на заявките от клиентската страна, т.е. ЧАСТ от “компилирането” се извършва от приложението, а СУБД го приема като (полу)готов за изпълнение код. В PHP “подготовка на заявките от страна на клиента” (client-side prepared statements) се поддържа от разширението PDO. На този етап това предлага доста по-бързо изпълнение на подготвени заявки изпълнени еднократно, но е значително по-бавно при многократно изпълнение на една и съща заявка спрямо “подготовката от страна на сървъра” (server-side prepared statements, което разгледахме като практика по-горе).

Обобщение: Използвайте подготвени и параметризирани заявки тогава, когато се налага да изпълнявате една и съща заявка множество пъти. Когато е възможно винаги се възползвайте от интерфейсите за подаване на подготвени заявки, а не SQL интерфейса, но в същото време не забравяйте стриктно да затваряте неактивните връзки към базата данни. Подготвените заявки НЕ трябва да се използват като основно средство за сигурност.

1. Punks Not Dead – 1981
2. Troops of Tomorrow – 1982
3. Let’s Start a War… (Said Maggie One Day) – 1983
4. Horror Epics – 1985
5. Death Before Dishonour – 1987
6. The Massacre – 1990
7. Beat the Bastards – 1996
8. Fuck the System – 2003

Кога ще излезе следващия албум?

Можем да представим поредицата от текущите албуми като една редица. Ще се интересуваме от интервала между издаваните албуми, като първия ще го приемем за “началото на епохата”, т.е. стойност 0. Разликата между първия и втория албум е една година, разликата между втория и третия е една година, разликата между третия и четвъртия е 2 и т.н. Получава се следната редица:

0 1 1 2 2 3 6 7

Ако знаем следващото число от редицата, то ще можем да кажем и през коя година ще бъде издаден албума. Какво казва математиката?

Търсим функция f(x) такава, че:

f(1) = 0
f(2) = 1
f(3) = 1
f(4) = 2
f(5) = 2
f(6) = 3
f(7) = 6
f(8) = 7

Има два популярни начина да намерим полином, който “минава” през тези точки. Първият е интерполационния полином на Лагранж:

0(x-2)(x-3)(x-4)(x-5)(x-6)(x-7)(x-8) / ((1-2)(1-3)(1-4)(1-5)(1-6)(1-7)(1-8))+
1(x-1)(x-3)(x-4)(x-5)(x-6)(x-7)(x-8) / ((2-1)(2-3)(2-4)(2-5)(2-6)(2-7)(2-8))+
1(x-1)(x-2)(x-4)(x-5)(x-6)(x-7)(x-8) / ((3-1)(3-2)(3-4)(3-5)(3-6)(3-7)(3-8))+
2(x-1)(x-2)(x-3)(x-5)(x-6)(x-7)(x-8) / ((4-1)(4-2)(4-3)(4-5)(4-6)(4-7)(4-8))+
2(x-1)(x-2)(x-3)(x-4)(x-6)(x-7)(x-8) / ((5-1)(5-2)(5-3)(5-4)(5-6)(5-7)(5-8))+
3(x-1)(x-2)(x-3)(x-4)(x-5)(x-7)(x-8) / ((6-1)(6-2)(6-3)(6-4)(6-5)(6-7)(6-8))+
6(x-1)(x-2)(x-3)(x-4)(x-5)(x-6)(x-8) / ((7-1)(7-2)(7-3)(7-4)(7-5)(7-6)(7-8))+
7(x-1)(x-2)(x-3)(x-4)(x-5)(x-6)(x-7) / ((8-1)(8-2)(8-3)(8-4)(8-5)(8-6)(8-7)) = f(x)

Другият е формулата на Нютон за разделените разлики):

f(x) = x-1-
(x-1)(x-2)/2+
2(x-1)(x-2)(x-3)/(2*3)-
4(x-1)(x-2)(x-3)(x-4)/(2*3*4)+
8(x-1)(x-2)(x-3)(x-4)(x-5)/(2*3*4*5)-
13(x-1)(x-2)(x-3)(x-4)(x-5)(x-6)/(2*3*4*5*6)+
14(x-1)(x-2)(x-3)(x-4)(x-5)(x-6)(x-7)/(2*3*4*5*6*7)

И двата полинома се опростяват (интерполационния полином на Лагранж и формулата на Нютон дават като резултат едни и същи полиноми) до:

f(x) = x^7/360-23x^6/240+193x^5/144-469x^4/48+28613x^3/720-1337x^2/15+1211x/12-43

Вече можем да потърсим колко години ще е разликата между 8мия и 9тия албум на групата:

f(9) = 9^7/360-23*9^6/240+193*9^5/144-469*9^4/48+28613*9^3/720-1337*9^2/15+1211*9/12-43

=> f(9) = 8

Това е и следващото число от поредицата. Тоест The Exploited би трябвало да издадат албума си през 2003+8 = … 2011г. Е, за наше голямо съжаление групата НЕ издаде албум през 2011г., т.е. каквото и да правят в момента – хей момчета, изоставате от графика си!

Разбира се горните съждения бяха тотално погрешни, защото когато и да издадат нов албум, ние винаги можем да намерим нов полином, който минава през всички точки, включително новата. Той просто ще е от по-висока с единица степен. Ако например приемем, че The Exploited ще издадат нов албум догодина (т.е. 2013г., ха дано), то разликата с последния албум ще е 10 години и редицата ще е станала 0 1 1 2 2 3 6 7 10. Интерполационният полином ще е:

0(x-2)(x-3)(x-4)(x-5)(x-6)(x-7)(x-8)(x-9) / ((1-2)(1-3)(1-4)(1-5)(1-6)(1-7)(1-8)(1-9))+
1(x-1)(x-3)(x-4)(x-5)(x-6)(x-7)(x-8)(x-9) / ((2-1)(2-3)(2-4)(2-5)(2-6)(2-7)(2-8)(2-9))+
1(x-1)(x-2)(x-4)(x-5)(x-6)(x-7)(x-8)(x-9) / ((3-1)(3-2)(3-4)(3-5)(3-6)(3-7)(3-8)(3-9))+
2(x-1)(x-2)(x-3)(x-5)(x-6)(x-7)(x-8)(x-9) / ((4-1)(4-2)(4-3)(4-5)(4-6)(4-7)(4-8)(4-9))+
2(x-1)(x-2)(x-3)(x-4)(x-6)(x-7)(x-8)(x-9) / ((5-1)(5-2)(5-3)(5-4)(5-6)(5-7)(5-8)(5-9))+
3(x-1)(x-2)(x-3)(x-4)(x-5)(x-7)(x-8)(x-9) / ((6-1)(6-2)(6-3)(6-4)(6-5)(6-7)(6-8)(6-9))+
6(x-1)(x-2)(x-3)(x-4)(x-5)(x-6)(x-8)(x-9) / ((7-1)(7-2)(7-3)(7-4)(7-5)(7-6)(7-8)(7-9))+
7(x-1)(x-2)(x-3)(x-4)(x-5)(x-6)(x-7)(x-9) / ((8-1)(8-2)(8-3)(8-4)(8-5)(8-6)(8-7)(8-9))+
10(x-1)(x-2)(x-3)(x-4)(x-5)(x-6)(x-7)(x-8) / ((9-1)(9-2)(9-3)(9-4)(9-5)(9-6)(9-7)(9-8)) = f(x)

=> f(x) = x^8/20160+x^7/1008-11x^6/160+803x^5/720-8311x^4/960+2621x^3/72-419701x^2/5040+20051x/210-41

Ако приемете друга година, например 2015, то редицата ще стане 0 1 1 2 2 3 6 7 12 и вие лесно ще намерите друг интерполационен полином. Всъщност:

• Което и число да сложите на края на която и да е редица, винаги ще съществува полином, който да я интерполира по показания начин!

Следователно задачите от типа “познайте следващото число в редицата” винаги имат лесно тривиално решение по алгоритъм с намиране на интерполационен полином. Дали обаче то е “решението, което човека търси” е напълно субективен фактор. Всъщност решение на задачата “намерете следващото число от редицата x1, x2, x3, …, xn” може да е което и да е число по ваш дори произволен избор. Затова когато някой ви даде задача от типа “намерете следващото число…” се обърнете към него и му кажете смело “следващото число е ПЕТ!”. И няма да сбъркате – ще можете да му намерите формула, по която наистина ще се получава, че числото е точно 5 :)

Снимка от Listal

Едно е сигурно – поколенията деца и юноши от онези години няма да го забравим и винаги ще остане в сърцата ни! По онова време бях наистина много малък, но няма да забравя “менкането” на аудио касетки, както и по колко десетки пъти се слушаше отново и отново всяка една от тях. Бях първият човек (поне в рамките на училището), който намери запис на албума “In Utero” (не пълен, а с две-три пропуснати песни). Беше велико (момичетата ми се молеха да им го дам :P). Днес намерих аудио касетката, която даже още е “жива” и дава чудесен звук.

Предлагам ви да изслушате няколко от най-любимите ми песни на Нирвана (аз всъщност като се замисля от Нирвана нямам “нелюбими”):

Lounge Act

Lithium

Aneurysm

Sappy

Heart Shaped Box

Rape Me

About a girl

Plateau

Oh Me!

You know you are right

In Bloom

I hate myself and I wanna die

School

Milk it!

Something in the way

Всяка заявка EXPLAIN връща като резултат таблица с 9 колони. Нека да разгледаме пълния им списък и възможните стойности, като дадем кратко описание:

• id – идентификационен номер на SELECT заявката. Вървят по ред започвайки от 1. Така може да разберете коя от вложените заявки се изпълнява първа, коя втора и т.н.
• select_type– Типа на SELECT заявката, който е един от следните:
  • SIMPLE – проста SELECT заявка без вложени заявки или UNION.
  • PRIMARY – най-външната (обрграждаща другите) заявка
  • UNION – заявка, резултатът от която ще бъде обединен към друга
  • DEPENDENT UNION – UNION заявка, която е вътрешна за друга заявка
  • SUBQUERY – вложен SELECT
  • DEPENDENT SUBQUERY – вложен SELECT, който е зависим от външни за него данни
  • DERIVED – SELECT заявка във FROM условие
• table – име на таблицата
• type– тип на заявката
  • CONST – указва, че таблицата има първичен или уникален ключ, който се използва в условие за сравнение. Това означава, че винаги ще има не повече от един ред в резултатната таблица от заявката, което впрочем прави такива заявки доста бързи – MySQL спира прелистването при намиране на съвпадение.
  • SYSTEM – const заявка върху системна таблица
  • EQ_REF – използва се UNIQUE и NOT NULL ключ. Това например може да се случи в JOIN заявка с класическа връзка 1:1. Това е най-бързият възможен JOIN, защото присъединяваната таблица винаги връща един ред и прелистването спира дотам.
  • REF – използва се неуникален ключ без NULL стойности. Това например може да е връзка 1:M.
  • REF_OR_NULL – използва се неуникален ключ, който може да има NULL стойности.
  • INDEX_MERGE – специален случай, в който MySQL сам обединява индекси в един множествен. Обикновено се случва при наличието на условия OR в WHERE частта на заявката.
  • UNIQUE_SUBQUERY – имаме вложен SELECT (извикан с оператор IN), който връща уникални стойности (без повторения).
  • INDEX_SUBQUERY – същото като предишното, но вложения SELECT връща стойности с повторения.
  • RANGE – използва се множество от стойности върху индекса. Например оператор BETWEEN, <, >, <=, >= и т.н.
  • INDEX – указва, че ще бъде преровен ЦЕЛИЯТ index, т.е. ще се прелистят всичките му стойности.
  • ALL – ще бъде направен FULL TABLE SCAN върху таблицата. Това е най-бавната възможна операция.
• possible_keys – възможните индекси, които MySQL може да използва за конкретната заявка.
• key – кой от възможните индекси е избран за конкретната заявка.
• key_len – колко байта от индекса ще се използват.
• rows – колко реда ще бъдат прелистени. Колкото по-малко, толкова по-добре.
• Extra– допълнителна информация.
  • Distinct – сървъра ще направи оптимизация като спре да търси повече колони при наличие на първо съвпадение (т.е. дублиращите ще се пропуснат)
  • Not exists – сървъра ще спре да търси повече съвпадения при първо такова в JOIN клауза.
  • range checked for each record – сървърът не е намерил подходящ индекс, но въпреки това ще прави пълно обхождане на съществуващ такъв, вместо FULL TABLE SCAN.
  • Using filesort – сървърът не използва индекс при сортирането.
  • Using index – сървърът използва индекс при сортирането.
  • Using temporary – ще се наложи създаване на временна таблица.
  • Using where – в заявката е използвана WHERE клауза за лимитиране на изхода.

Преди да започнем с практически примери ще ни трябва база от данни с достатъчно голямо количество информация. Нека например вземем world-innodb, която е дадена като примерна на сайта на MySQL. Тя има следната структура:

CREATE TABLE `country` (
  `Code` char(3) NOT NULL DEFAULT '',
  `Name` char(52) NOT NULL DEFAULT '',
  `Continent` enum('Asia','Europe','North America',
                   'Africa','Oceania','Antarctica',
                   'South America') 
              NOT NULL DEFAULT 'Asia',
  `Region` char(26) NOT NULL DEFAULT '',
  `SurfaceArea` float(10,2) NOT NULL DEFAULT '0.00',
  `IndepYear` smallint(6) DEFAULT NULL,
  `Population` int(11) NOT NULL DEFAULT '0',
  `LifeExpectancy` float(3,1) DEFAULT NULL,
  `GNP` float(10,2) DEFAULT NULL,
  `GNPOld` float(10,2) DEFAULT NULL,
  `LocalName` char(45) NOT NULL DEFAULT '',
  `GovernmentForm` char(45) NOT NULL DEFAULT '',
  `HeadOfState` char(60) DEFAULT NULL,
  `Capital` int(11) DEFAULT NULL,
  `Code2` char(2) NOT NULL DEFAULT '',
  PRIMARY KEY (`Code`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `city` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Name` char(35) NOT NULL DEFAULT '',
  `CountryCode` char(3) NOT NULL DEFAULT '',
  `District` char(20) NOT NULL DEFAULT '',
  `Population` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`ID`),
  KEY `CountryCode` (`CountryCode`),
  CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) 
                           REFERENCES `country` (`Code`)
) ENGINE=InnoDB AUTO_INCREMENT=4080 DEFAULT CHARSET=latin1;

CREATE TABLE `countrylanguage` (
  `CountryCode` char(3) NOT NULL DEFAULT '',
  `Language` char(30) NOT NULL DEFAULT '',
  `IsOfficial` enum('T','F') NOT NULL DEFAULT 'F',
  `Percentage` float(4,1) NOT NULL DEFAULT '0.0',
  PRIMARY KEY (`CountryCode`,`Language`),
  KEY `CountryCode` (`CountryCode`),
  CONSTRAINT `countryLanguage_ibfk_1` 
                FOREIGN KEY (`CountryCode`)
                REFERENCES `country` (`Code`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Нека разгледаме нашата първа елементарна заявка – искаме да изведем броят на държавите, които са с управление от тип ‘Republic’. Ето какво ще върне EXPLAIN на една такава заявка ако нямаме създадени никакви допълнителни индекси:

mysql> EXPLAIN SELECT COUNT(*)
    -> FROM country
    -> WHERE GovernmentForm = 'Republic';
+----+---------+------+---------------+------+---------+------+------+
| id | table   | type | possible_keys | key  | key_len | ref  | rows |
+----+---------+------+---------------+------+---------+------+------+
|  1 | COUNTRY | ALL  | NULL          | NULL | NULL    | NULL |  233 |
+----+---------+------+---------------+------+---------+------+------+
1 row in set (0.00 sec)

Първата важна колона, която трябва да разгледаме е “possible_keys”. Тя ни указва кои са индексите, които MySQL може да използва в заявката. В случая няма нито един индекс, който може да бъде използван. Съответно MySQL няма да използва никакъв индекс (стойността под key е NULL). Другата важна за нас колона е “rows” – тя показва колко реда са били прегледани, преди да се достигне до желания резултат. В случая са били прелистени 233 реда.

Ако вие използвате SELECT заявка, която не използва Index, то много често това означава, че можете да подобрите бързодействието чрез създаване на такъв. Нека да видим:

ALTER TABLE country
ADD INDEX GovernmentFormIndex (GovernmentForm);

mysql> EXPLAIN SELECT COUNT(*)
    -> FROM country
    -> WHERE GovernmentForm = 'Republic';
+---------+------+---------------------+---------------------+---------+-------+------+
| table   | type | possible_keys       | key                 | key_len | ref   | rows |
+---------+------+---------------------+---------------------+---------+-------+------+
| COUNTRY | ref  | GovernmentFormIndex | GovernmentFormIndex | 45      | const |  122 |
+---------+------+---------------------+---------------------+---------+-------+------+

Виждаме, че вече има възможен индекс, MySQL го е избрал и най-важното – прелистените редове са почти два пъти по-малко, отколкото преди – 122. Това в общия случай ще означава, че SQL заявката ще се изпълнява близо два пъти по-бързо.

Разбира се индексите силно зависят от данните, които се записват в тях и обемът от информация, който се използва. Ето ви друг пример – искаме да изведем броят на градовете, които имат население над 5000 души. Първата заявка ще изпълним без индекс, а втората с:

mysql> EXPLAIN SELECT COUNT(*)
    -> FROM city
    -> WHERE city.population > 5000;
+-------+------+---------------+------+---------+------+------+
| table | type | possible_keys | key  | key_len | ref  | rows |
+-------+------+---------------+------+---------+------+------+
| city  | ALL  | NULL          | NULL | NULL    | NULL | 4234 |
+-------+------+---------------+------+---------+------+------+
1 row in set (0.00 sec)

mysql> ALTER TABLE city
    -> ADD INDEX population (population);
Query OK, 0 rows affected (0.52 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> EXPLAIN SELECT COUNT(*)
    -> FROM city
    -> WHERE city.population > 5000;
+-------+-------+---------------+------------+---------+------+------+
| table | type  | possible_keys | key        | key_len | ref  | rows |
+-------+-------+---------------+------------+---------+------+------+
| city  | range | population    | population | 4       | NULL | 4048 |
+-------+-------+---------------+------------+---------+------+------+
1 row in set (0.00 sec)

Виждаме, че тук създадохме индекс, той се използва, но резултатът в не е значителен – имаме само малко намаление на броя прелистени редове. Това се получава така, понеже почти всички градове в базата от данни са с повече от 5000 души, т.е. ние използваме почти цялата таблица, което се свежда доста близко до обикновен full table scan. Нека променим условието и изведем броят на градовете с над 1 милион души:

mysql> ALTER TABLE city
    -> DROP INDEX population;
Query OK, 0 rows affected (0.16 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> EXPLAIN SELECT COUNT(*)
    -> FROM city
    -> WHERE city.population > 1000000;
+-------+------+---------------+------+---------+------+------+
| table | type | possible_keys | key  | key_len | ref  | rows |
+-------+------+---------------+------+---------+------+------+
| city  | ALL  | NULL          | NULL | NULL    | NULL | 4234 |
+-------+------+---------------+------+---------+------+------+
1 row in set (0.00 sec)

mysql> ALTER TABLE city
    -> ADD INDEX population (population);
Query OK, 0 rows affected (0.22 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> EXPLAIN SELECT COUNT(*)
    -> FROM city
    -> WHERE city.population > 1000000;
+-------+-------+---------------+------------+---------+------+------+
| table | type  | possible_keys | key        | key_len | ref  | rows |
+-------+-------+---------------+------------+---------+------+------+
| city  | range | population    | population | 4       | NULL |  237 |
+-------+-------+---------------+------------+---------+------+------+
1 row in set (0.00 sec)

Тук вече виждаме огромна разлика от близо 18 пъти по-малко прелиствания! Или колкото по-ограничено е количеството на данни в резултатната таблица, толкова по-ефективен е индекса.

По интересен става случаят, когато имаме логическа връзка между две колони. Нека изведем Европейските държави, които имат население над 40 милиона души:

mysql> EXPLAIN SELECT name
    -> FROM country
    -> WHERE population > 40000000
    ->       AND
    ->       Continent="Europe";
+---------+------+---------------+------+------+
| table   | type | possible_keys | key  | rows |
+---------+------+---------------+------+------+
| country | ALL  | NULL          | NULL |  233 |
+---------+------+---------------+------+------+
1 row in set (0.00 sec)

mysql> ALTER TABLE country
    -> ADD INDEX populationIndex (population);
Query OK, 0 rows affected (0.47 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> ALTER TABLE country
    -> ADD INDEX continentIndex (Continent);
Query OK, 0 rows affected (0.19 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> EXPLAIN SELECT name
    -> FROM country
    -> WHERE population > 40000000
    ->       AND
    ->       Continent="Europe";
+---------+------+--------------------------------+----------------+------+
| table   | type | possible_keys                  | key            | rows |
+---------+------+--------------------------------+----------------+------+
| country | ref  | populationIndex,continentIndex | continentIndex |   46 |
+---------+------+--------------------------------+----------------+------+
1 row in set (0.00 sec)

Тук виждаме нещо интересно – има два възможни индекса, от които MySQL си е избрал един. Нека видим какъв ще бъде резултата, ако използваме другия индекс (можем да принудим MySQL да го използва чрез командата USE INDEX след FROM):

mysql> EXPLAIN SELECT name
    -> FROM country
    -> USE INDEX(populationIndex)
    -> WHERE population > 40000000
    ->       AND
    ->       Continent="Europe";
+---------+-------+-----------------+-----------------+---------+------+------+
| table   | type  | possible_keys   | key             | key_len | ref  | rows |
+---------+-------+-----------------+-----------------+---------+------+------+
| country | range | populationIndex | populationIndex | 4       | NULL |   28 |
+---------+-------+-----------------+-----------------+---------+------+------+
1 row in set (0.00 sec)

Ясно се вижда, че в зависимост от заявката, използването на един или друг индекс ще доведе до различно бързодействие. Причината в случая от примера е, че индексът continentIndex “не е достатъчно уникален”, т.е. в колоната има доста повторения, докато при populationIndex повторенията са много малко.

Вече можем да си изведем първи два основни извода за оптимизиране на заявки:

• Колкото по-уникална (с различни стойности по редове) е една колона, толкова по-ефективни ще са индексите, които се правят по нея;
• При по-ограничен изход от заявките (т.е. извличат се по-малко редове от оригиналната в изходната таблица) се получава по-голяма разлика в бързодействието между използването на индекс и full table scan.

Обратно – ако трябва да изведем информация от всички редове в съществуваща таблица или по дадената колона имаме много повторения на стойности, то индексите започват да губят ефект.

Можем ли да използваме повече от един индекс върху една таблица? Отговорът за MySQL е отрицателен – не може. Това, което можем да направим обаче е да се възползваме от “множествени индекси”, т.е. индекси създадени по повече от една колона. Ето пример с предишната заявка:

mysql> ALTER TABLE country
    -> ADD INDEX pop_cont_index (Continent, population);
Query OK, 0 rows affected (0.20 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> EXPLAIN SELECT name
    -> FROM country
    -> USE INDEX(pop_cont_index)
    -> WHERE population > 40000000
    ->       AND
    ->       Continent="Europe";
+---------+-------+----------------+----------------+---------+------+------+
| table   | type  | possible_keys  | key            | key_len | ref  | rows |
+---------+-------+----------------+----------------+---------+------+------+
| country | range | pop_cont_index | pop_cont_index | 5       | NULL |    6 |
+---------+-------+----------------+----------------+---------+------+------+
1 row in set (0.00 sec)

Виждаме, че тук имаме гигантска разлика! Оригиналната заявка (без индекси) имаше нужда от 233 прелиствания, а с използването на правилния индекс ги сведохме до само 6, което е с близо 39 пъти по-високо бързодействие!

Тук е много важно да отбележим нещо – при създаването на множествени индекси е много важна подредбата на колоните. Ако например в предишната заявка ги “обърнем” и сложим колоната population преди continent, то ще се получи следното:

mysql> ALTER TABLE country
    -> DROP INDEX pop_cont_index;
Query OK, 0 rows affected (0.16 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> ALTER TABLE country
    -> ADD INDEX pop_cont_index (population, Continent);
Query OK, 0 rows affected (0.52 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> EXPLAIN SELECT name
    -> FROM country
    -> USE INDEX(pop_cont_index)
    -> WHERE population > 40000000
    ->       AND
    ->       Continent="Europe";
+---------+-------+----------------+----------------+---------+------+------+
| table   | type  | possible_keys  | key            | key_len | ref  | rows |
+---------+-------+----------------+----------------+---------+------+------+
| country | range | pop_cont_index | pop_cont_index | 4       | NULL |   28 |
+---------+-------+----------------+----------------+---------+------+------+
1 row in set (0.00 sec)

Виждаме, че тук изгубихме ефекта от добавянето на continent в индекса. Това е така, понеже стойностите по редове в колона population са доста различни (почти без повторения), т.е. на изолираната единична стойност няма какво допълнително да се оптимизира. Ето как можем да изкараме още една зависимост:

• При използване на множествен индекс в общия случай ще по-добре да слагаме първо колоната с повече повторения, а след нея по-уникалната такава.

Това “правило” разбира се може лесно да получи впечатляващи изключения (главно тогава, когато се окаже, че въобще не е нужно да бъде използвана една от двете колони). Затова винаги проверявайте и правете тестове. Също така имайте в предвид, че когато в условието WHERE на заявката има логическо OR ще е особено подходящо да използвате именно множествен индекс.

Нуждата от оптимизация на заявките идва особено важна когато ни се налага да използваме JOIN между две и повече таблици. Тук EXPLAIN ще ни дава информация за всяка една от таблиците използвани във FROM условието:

mysql> EXPLAIN SELECT country.Name as country, city.Name as city
    -> FROM country JOIN city ON country.code = city.countryCode
    -> WHERE country.Continent = "Europe";
+---------+---------------------------------------+----------------+--------------------+------+
| table   | possible_keys                         | key            | ref                | rows |
+---------+---------------------------------------+----------------+--------------------+------+
| country | PRIMARY,continentIndex,pop_cont_index | continentIndex | const              |   46 |
| city    | CountryCode                           | CountryCode    | world.country.Code |    7 |
+---------+---------------------------------------+----------------+--------------------+------+
2 rows in set (0.00 sec)

Виждаме, че тук има няколко възможни индекса. Индексите continentIndex и pop_cont_index за country ги създадохме ние в предишни заявки. Индексите PRIMARY за country и CountryCode за city са създадени автоматично при създаването на таблиците в MySQL. Последното е така, понеже едното е primary key, а другото е foreign key. За всички ключови колони по подразбиране се създават индекси. Тук при по-сложни WHERE условия също е добре да следим индексите, които се използват и при нужда да указваме кой от тях да бъде употряван или да създаваме допълнителни множествени.

Освен кой индекс да се използва има и някои други неща, които трябва да следим. Важна е и колона EXTRA от резултата на EXPLAIN заявката. Там ще виждате различни стойности, сред които “using where”, “using index”, “using filesort”, “using temporarily table” и др. Ако там специално присъства “using filesort” (може да се появи когато използвате ORDER BY), то това означава, че по време на сортирането не се използва индекс. Ето един пример:

mysql> EXPLAIN SELECT name
    -> FROM city
    -> ORDER BY name DESC;
+-------+------+---------------+------+---------+------+------+----------------+
| table | type | possible_keys | key  | key_len | ref  | rows | Extra          |
+-------+------+---------------+------+---------+------+------+----------------+
| city  | ALL  | NULL          | NULL | NULL    | NULL | 4234 | Using filesort |
+-------+------+---------------+------+---------+------+------+----------------+
1 row in set (0.00 sec)

Използването на индекс тук ще разреши проблема:

ALTER TABLE city
ADD INDEX nameIndex (name);

mysql> EXPLAIN SELECT name
    -> FROM city
    -> ORDER BY name DESC;
+-------+-------+---------------+-----------+---------+------+------+-------------+
| table | type  | possible_keys | key       | key_len | ref  | rows | Extra       |
+-------+-------+---------------+-----------+---------+------+------+-------------+
| city  | index | NULL          | nameIndex | 35      | NULL | 4234 | Using index |
+-------+-------+---------------+-----------+---------+------+------+-------------+
1 row in set (0.00 sec)

Така можем да изведем още едно “правило”:

• Сортирането с индекс почти винаги е по-добро от такова без. При “лош индекс” (колона с много повторения) бързината при двете сортирания може да се доближи. Но дори тогава ако изходните данни са с много голям обем, то е възможно системата да изпита недостиг на оперативна памет (големината на sort_buffer променливата в my.cnf дефинира максимален лимит) и от там нататък MySQL ще трябва да създаде временна (temporarily) таблица на хард диска. Достигането до такава ситуация винаги е “убиец на производителност”. С използването на индекси при сортирането рядко ще достигаме до такива моменти. Така, че ако видите “using index” в колона “Extra”, то би трябвало всичко да е наред, докато “using filesort” не.

И накрая, но не последно – създаването на излишни или лошо работещи индекси е вредно за производителността на системата. Причината е, че те също отнемат ресурси, за да бъдат поддържани. Поради тази причина можем да изведем последното (за статията) условие:

• Създавайте само индекси, които ще използвате често

За всяка статия се пази нейното заглавие (до 160 символа) и съдържание (количество текстова информация, което ще е подходящо за поле от тип TEXT) и дата на публикуване. Когато някой автор добави нова статия в системата тя стандартно ще отива в „опашка за рецензиране“ (moderation queue). Това означава, че трябва някой рецензент да я провери и редактира преди да бъде официално публикувана. Статии, които не успеят да преминат успешно рецензия просто ще се изтриват. За статиите, които са одобрени задължително се пази информация за това кой е бил рецензента, който ги е одобрил.

Задача 1. Направете ER диаграма на описаната горе база от данни, създайте я в MySQL и вмъкнете примерни данни в нея.

Задача 2. Изведете списък със статиите на автор с име „Ivan”, които все още не са рецензирани.

Задача 3. Изведете списък с имената на авторите, общия им брой рецензирани статии и общия им брой нерецензирани статии (т.е. които все още очакват рецензия). Потребителите, които въобще нямат статии да се пропуснат.

Решение: Първо да определим данните, които ще се пазят със сигурност в базата от данни. Това са:

• Уникални номера на потребителите;
• Потребителски имена;
• Заглавия на статиите;
• Съдържания на статиите;
• Дати на публикуване на статиите;
• Кой потребител е автор на дадена статия;
• Кой потребител е рецензент на дадена статия (ако е рецензирана).

Очевидно зависимите данни са уникалните номера на потребителите и потребителските имена от една страна и заглавията, съдържанието и датата на публикуване за статиите от друга. Те могат да характеризират два класа обекти – Потребители (users) и Статии (articles). Ясно се вижда, че “Кой потребител е автор на дадена статия” и “Кой потребител е рецензент на дадена статия (ако е рецензирана)” са връзки между тези два класа. Тоест ER диаграмата на този етап е следната:

Очевидният първичен ключ за таблица Users е атрибута id. За таблица Articles няма нито очевиден такъв, нито подходящ, затова при създаването на таблицата ще направим допълнителен атрибут “id” (редно е да се отрази и в ER диаграмата – направете го).

Колкото до връзките – всяка таблица задължително трябва да има автор, т.е. author_id ще бъде NOT NULL, докато някои статии ще са рецензирани, а други не – т.е. moderator_id ще може евентуално да бъде NULL.

В условието има още важни неща, а именно:

• “Всеки потребител може да има три основни роли“, което е допълнено с “Разбира се авторите и рецензентите сами по себе си са обикновени потребители. Освен това не е забранено на даден автор да бъде и рецензент на други статии.“. Това практически означава, че всеки един потребител на системата може да заема всякаква роля – в задачата никъде не е дефинирано ограничение от типа, че “някоя конкретна група потребители не може да заема дадена роля” или “само тези и тези потребители могат да бъдат автори/рецензенти”. Следователно не е нужно да правим подкласове на класа обекти Users – всеки един потребител може потенциално да бъде както автор, така и рецензент. В случая каква роля заема за дадена статия ще се определя от връзките между статията и потребителите.
• “Когато някой автор добави нова статия в системата тя стандартно ще отива в „опашка за рецензиране“ (moderation queue)” – тук въпросът е дали има нужда да добавим още един атрибут в класа Articles с тип данни BIT, който да има смисъла на “одобрена” и “неодобрена” статия в зависимост от стойноста? Не е изключено да го направим (по-скоро би било полезно), но в случая можем и да си го спестим – статиите, които имат въведен moderator_id ще приемаме за “рецензирани”, а там, където moderator_id е NULL ще приемаме за “нерецензирани”. В реална ситуация по-скоро бихме приели варианта с допълнителния атрибут, понеже така даваме шанс за създаване на нови функционалности като “някой рецензент е заключил статия за себе си, но все още не я е рецензирал” или “статията е била рецензирана услешно, но рецензентът е бил изтрит от системата и вече нямаме неговото id”. В решението по-долу ще се спрем върху по-лесния вариант (без специална колона за статус в таблицата Articles), а вие в последствие преправете заявките с другия.
• Колкото до нуждата от създаване на “опашка от нерецензирани статии” – това може много лесно да бъде реализирано, като се извадят записите с NULL стойност в колона moderator_id от таблица Articles и в последствие се сортират по датата на тяхното въвеждане. Тоест и за опашката няма да е необходимо да пазим допълнителна информация.

Нека сега създадем въпросната база от данни:

CREATE DATABASE usersystem;
USE usersystem;

CREATE TABLE users(
  id SMALLINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255) UNIQUE NOT NULL
)ENGINE = InnoDB CHARACTER SET utf8;

CREATE TABLE articles(
  id INT UNSIGNED AUTO_INCREMENT  PRIMARY KEY,
  title VARCHAR(160) NOT NULL,
  contents TEXT NOT NULL,
  author_id SMALLINT UNSIGNED NOT NULL,
  published_on DATE NOT NULL,
  FOREIGN KEY (author_id) REFERENCES users(id)
          ON DELETE RESTRICT ON UPDATE RESTRICT,
  moderator_id SMALLINT UNSIGNED NULL DEFAULT NULL,
  FOREIGN KEY (moderator_id) REFERENCES users(id)
          ON DELETE RESTRICT ON UPDATE RESTRICT
)ENGINE = InnoDB CHARACTER SET utf8;

и да въведем примерни данни:

INSERT INTO users(name)
VALUES ("Petar"), ("Ivan"), ("Maria"), ("Philip");

INSERT INTO articles(title, contents, published_on, author_id, moderator_id)
VALUES ("Статия 1", "Съдържание към статия 1...", "2012-03-12", 2, NULL),
       ("Статия 2", "Съдържание към статия 2...", "2012-03-28", 3, NULL),
       ("Статия 3", "Съдържание към статия 3...", "2012-04-04", 3, NULL),
       ("Статия 4", "Съдържание към статия 4...", "2012-02-27", 2, NULL),
       ("Статия 5", "Съдържание към статия 5...", "2012-03-28", 3, 1),
       ("Статия 6", "Съдържание към статия 6...", "2012-04-04", 3, 2),
       ("Статия 7", "Съдържание към статия 7...", "2012-02-27", 2, 1),
       ("Статия 8", "Съдържание към статия 8...", "2012-02-27", 1, 2),
       ("Статия 9", "Съдържание към статия 9...", "2012-02-27", 1, NULL);

Пристъпваме към решението на задача 2. То е повече от тривиално и няма нужда от специални обяснения:

SELECT title, contents, published_on
FROM articles
WHERE moderator_id IS NULL
      AND author_id = ( SELECT id
                        FROM users
                        WHERE name = "Ivan"
                      );

Сега трябва да помислим за задача 3. Лесно можем да изведем имената на хората и броя от рецензираните им статии чрез следната заявка:

SELECT users.id AS user_id, users.name as user_name
COUNT(articles.id) AS moderatedcount
FROM users JOIN articles ON users.id = articles.author_id
WHERE articles.moderator_id IS NOT NULL
GROUP BY users.id;

Лесно можем да изведем и имената на хората и броя на нерецензираните им статии чрез следната заявка:

SELECT users.id AS user_id, users.name as user_name
COUNT(articles.id) AS unmoderatedcount
FROM users JOIN articles ON users.id = articles.author_id
WHERE articles.moderator_id IS NULL
GROUP BY users.id;

Как обаче да ги обединим в една? Очевидното решение е като направим JOIN между тези две таблици. При това забележете, че трябва да е FULL JOIN, понеже е възможно както да има потребител без нито една рецензирана статия, така и потребител без нито една нерецензирана.

За съжаление знаем, че MySQL не поддържа FULL JOIN и се налага да се прави сложно чрез изкуствени методи. За щастие в тази конкретна задача и двете заявки произхождат от данни на една таблица – users. Тоест ние можем да направим следното – да вземем всички записи от таблица users, за всеки един от тях да добавим moderatedcount (може да е NULL, т.е. ще използваме LEFT JOIN) и към получения резултат за всеки един ред да добавим и unmoderatedcount (отново с LEFT JOIN). Накрая, понеже в задачата се изисква “потребителите, които въобще нямат статии да се пропуснат”, от резултатната таблица трябва да премахнем редовете, в които moderatedcount и unmoderatedcount заедно са с NULL стойности. Ето как би изглеждала такава заявка:

SELECT users.id,
       users.name,
       moderated_articles.moderatedcount,
       unmoderated_articles.unmoderatedcount
FROM users

     LEFT JOIN 
     ( SELECT users.id AS user_id, 
              COUNT(articles.id) AS moderatedcount
        FROM users JOIN articles ON users.id = articles.author_id
        WHERE articles.moderator_id IS NOT NULL
        GROUP BY users.id
     ) AS moderated_articles
     ON users.id = moderated_articles.user_id

     LEFT JOIN 
     ( SELECT users.id AS user_id,
              COUNT(articles.id) AS unmoderatedcount
        FROM users JOIN articles ON users.id = articles.author_id
        WHERE articles.moderator_id IS NULL
        GROUP BY users.id
     ) AS unmoderated_articles
     ON users.id = unmoderated_articles.user_id

GROUP BY users.id
HAVING moderatedcount IS NOT NULL 
       OR 
       unmoderatedcount IS NOT NULL;

Това е валидно решение на задачата. В този си вид обаче заявката въобще не е оптимална. Ето някои неща, които би трябвало да ни направят впечатление:

• В първата вложена заявка правим обхождане на таблицата users гледайки стойностите на колоната moderator_id и във втората пак правим същото обхождане гледайки стойностите по същата колона.
• Взимаме абсолютно всички потребители и за всички правим сметките. В зависимост от натоварването на подобна система може да се окаже така, че много от потребителите въобще не са автори, а са просто обикновени потребители или рецензенти. В такъв случай резултатната таблица (преди прилагането на HAVING) ще бъде ненужно голяма.

Затова можем да помислим и за “по-хитро” решение. Един начин е да си направим два “брояча” в една SELECT заявка и да използваме оператор IF, с който да добавяме 0 или 1 към съотвeтния брояч:

SELECT users.id,
       users.name,
       SUM(IF(articles.moderator_id IS NOT NULL, 1, 0))
	        AS moderatedcount,
       SUM(IF(articles.moderator_id IS NULL, 1, 0))
	        AS unmoderatedcount
FROM users JOIN articles ON users.id = articles.author_id
GROUP BY users.id;

При това решение забележете, че потребителите с едновременно 0 рецензирани и 0 одобрени статии автоматично се премахват още от INNER JOIN условието – тези потребители, които въобще нямат статия не участват в по-нататъшните сметки. Очевидно е, че тази заявка е много по-добра и дори по-пригледна от предишната.

Допълнителна задача: Направете така, че да не е възможно даден автор да е рецензент сам на себе си.

Събитията в MySQL се контролират от специална нишка, която работи паралелно с останалите. Преди да започнете да работите със събития трябва да проверите дали тя е включена (по подразбиране не е). Това се контролира от глобалната променлива “event_scheduler”. Ако нишката не е стартирана, то MySQL ще приема заявките ви за създаване на събития, но те няма да се изпълняват. За да проверите стойността на променливата напишете следната команда:

mysql> SELECT @@event_scheduler;
+-------------------+
| @@event_scheduler |
+-------------------+
| OFF               |
+-------------------+
1 row in set (0.00 sec)

За да я включите трябва да я промените на “ON”:

mysql> SET GLOBAL event_scheduler = "ON";
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @@event_scheduler;
+-------------------+
| @@event_scheduler |
+-------------------+
| ON                |
+-------------------+
1 row in set (0.00 sec)

Ако искате да го включите автоматично при рестартиране на MySQL добавете в my.cnf “event_scheduler = on”. Може да проверите, че нишката е стартирана разглеждайки списъка с процесите:

mysql> SHOW PROCESSLIST\G
*************************** 1. row
     Id: 1
   User: root
   Host: localhost:9737
     db: NULL
Command: Query
   Time: 0
  State: NULL
   Info: SHOW PROCESSLIST
*************************** 2. row
     Id: 2
   User: event_scheduler
   Host: localhost
     db: NULL
Command: Daemon
   Time: 74
  State: Waiting on empty queue
   Info: NULL
2 rows in set (0.00 sec)

Първият процес в списъка е този, който самите ние сме стартирали отваряйки връзка с потребител root към СУБД, а втория е въпросния “event scheduler”.

За да създадете събитие трябва да използвате командата CREATE EVENT. В най-елементарния си вариант тя има следния синтаксис:

CREATE EVENT <име>
ON SCHEDULE <график>
DO <коматди>

Пример 1: Нека демонстрираме с класически пример. Нека имаме база от данни, в която съхраняваме публикации и записи за влизанията в тях (log). За всяка публикация искаме да пазим статистика за уникалните посещения (visits), която се калкулира на база на записите за влизанията:

CREATE TABLE articles(
   id SMALLINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   title VARCHAR(255) NOT NULL,
   contents TEXT NOT NULL,
   visits INT UNSIGNED NOT NULL
)ENGINE=InnoDB CHARACTER SET=utf8;

INSERT INTO articles(title, contents, visits)
VALUES ("Статия 1", "Някакво съдържание...", 0),
       ("Статия 2", "Друго съдържание...", 0);

CREATE TABLE logs(
   article_id SMALLINT UNSIGNED,
   FOREIGN KEY (article_id) REFERENCES articles(id),
   ip INT UNSIGNED NOT NULL,
   hits INT NOT NULL,
   PRIMARY KEY(article_id,ip)
) ENGINE=InnoDB  CHARACTER SET=ascii;

Когато потребителите започнат да четат дадени статии, то ние ще взимаме IP адреса на всеки един от тях и ще правим запис в таблицата logs за съответното посещение.

Сега остава да разрешим проблема със съответствието на hits в таблицата logs и visits в таблицата articles. Разбира се вече знаем как да създадем тригер, който при добавяне на нов запис в таблицата logs ще обновява стойността на visits в таблицата articles. Ако обаче нашия сайт е достатъчно много натоварен (например имаме по няколко посещения в секунда) това може да се окаже неприятна операция (забележете, че при използване на InnoDB всяка UPDATE заявка сама по себе си е транзакция, т.е. имаме и заключване на данните). Разбира се ние можем напълно да се откажем от колона visits и всеки път когато даваме информацията на потребителите ни да си калкулираме стойността динамично, но това също не ни харесва от гледна точка на производителност.

Именно тук можем да използваме събитията – ще калкулираме статистиката за visits например веднъж на минута. Така потребителя няма да вижда най-актуалната статистика за посещенията към текущия момент, в който чете дадената статия, но в най-лошия случай ще вижда данните най-много от преди минута. За целта можем да добавим следното събитие:

CREATE EVENT visits_update
ON SCHEDULE EVERY 1 MINUTE
DO UPDATE articles
   SET visits = ( SELECT COUNT(*)
                  FROM logs
                  WHERE logs.article_id = articles.id
                );

Сега да вмъкнем примерни данни в logs:

INSERT INTO logs(article_id, ip, hits)
VALUES (1, INET_ATON('1.1.1.1'), 1),
       (2, INET_ATON('1.1.1.1'), 1),
       (1, INET_ATON('2.2.2.2'), 1),
       (1, INET_ATON('3.3.3.3'), 1),
       (1, INET_ATON('1.1.1.1'), 1),
       (2, INET_ATON('2.2.2.2'), 1),
       (2, INET_ATON('3.3.3.3'), 1),
       (2, INET_ATON('3.3.3.3'), 1),
       (2, INET_ATON('3.3.3.3'), 1),
       (1, INET_ATON('4.4.4.4'), 1)
ON DUPLICATE KEY UPDATE hits=hits+1;

Първоначално ще видим, че visits не е обновено:

SELECT * FROM articles;
+----+----------+-----------------------+--------+
| id | title    | contents              | visits |
+----+----------+-----------------------+--------+
|  1 | Статия 1 | Някакво съдържание... |      0 |
|  2 | Статия 2 | Друго съдържание...   |      0 |
+----+----------+-----------------------+--------+
2 rows in set (0.00 sec)

Ако обаче почакаме една минута, то ще видим, че visits ще се обнови:

SELECT * FROM articles;
+----+----------+-----------------------+--------+
| id | title    | contents              | visits |
+----+----------+-----------------------+--------+
|  1 | Статия 1 | Някакво съдържание... |      4 |
|  2 | Статия 2 | Друго съдържание...   |      3 |
+----+----------+-----------------------+--------+
2 rows in set (0.00 sec)

Можем ли да помислим за някаква оптимизация? Разбира се, че може. Защо всеки път обновяваме посещенията пресмятайки броя на всички записи в таблицата, а не просто да добавяме броя само на новите такива? Ще го направим, като от тук нататък ще разглеждаме таблицата logs като “дневни записи” (т.е. ще записваме TIME). Естествено не е проблем да се направят и “месечни” или “вечни”:

DROP EVENT visits_update;

TRUNCATE TABLE logs;

ALTER TABLE articles
ADD COLUMN last_visits_update DATETIME NOT NULL;

UPDATE articles
SET last_visits_update = NOW(), visits = 0;

ALTER TABLE logs
ADD COLUMN at_time TIME NOT NULL;

Изтрихме записите в logs и добавихме нови колони – последно обновяване в articles и време на първото посещение на даден IP адрес в logs. Сега пренаписваме събитието така, че да удовлетворява новото условие:

CREATE EVENT visits_update
ON SCHEDULE EVERY 1 MINUTE
DO UPDATE articles
   SET visits = visits +
                ( SELECT COUNT(*)
                  FROM logs
                  WHERE logs.article_id = articles.id
                        AND
                        logs.at_time > TIME(articles.last_visits_update)
                ),
       last_visits_update = NOW();

Добавяме новите записи:

INSERT INTO logs(article_id, ip, hits, at_time)
VALUES (1, INET_ATON('1.1.1.1'), 1, CURTIME()),
       (2, INET_ATON('1.1.1.1'), 1, CURTIME()),
       (1, INET_ATON('2.2.2.2'), 1, CURTIME()),
       (1, INET_ATON('3.3.3.3'), 1, CURTIME()),
       (1, INET_ATON('1.1.1.1'), 1, CURTIME()),
       (2, INET_ATON('2.2.2.2'), 1, CURTIME()),
       (2, INET_ATON('3.3.3.3'), 1, CURTIME()),
       (2, INET_ATON('3.3.3.3'), 1, CURTIME()),
       (2, INET_ATON('3.3.3.3'), 1, CURTIME()),
       (1, INET_ATON('4.4.4.4'), 1, CURTIME())
ON DUPLICATE KEY UPDATE hits=hits+1;

… и проверяваме. Първоначално статистиката няма да е обновена:

SELECT * FROM articles;
+----+----------+-----------------------+--------+---------------------+
| id | title    | contents              | visits | last_visits_update  |
+----+----------+-----------------------+--------+---------------------+
|  1 | Статия 1 | Някакво съдържание... |      0 | 2012-04-03 15:18:45 |
|  2 | Статия 2 | Друго съдържание...   |      0 | 2012-04-03 15:18:45 |
+----+----------+-----------------------+--------+---------------------+
2 rows in set (0.00 sec)

… но след една минута вече ще бъде:

SELECT * FROM articles;
+----+----------+-----------------------+--------+---------------------+
| id | title    | contents              | visits | last_visits_update  |
+----+----------+-----------------------+--------+---------------------+
|  1 | Статия 1 | Някакво съдържание... |      4 | 2012-04-03 15:19:45 |
|  2 | Статия 2 | Друго съдържание...   |      3 | 2012-04-03 15:19:45 |
+----+----------+-----------------------+--------+---------------------+
2 rows in set (0.00 sec)

Ако в последствие добавим нови записи със съществуващи стари (не трябва да обновява visits) и нови (трябва да обнови visits) IP адреси:

INSERT INTO logs(article_id, ip, hits, at_time)
VALUES (1, INET_ATON('5.5.5.5'), 1, CURTIME()),
       (1, INET_ATON('1.1.1.1'), 1, CURTIME()),
       (1, INET_ATON('6.6.6.6'), 1, CURTIME())
ON DUPLICATE KEY UPDATE hits=hits+1;

… ще видим, че обновяването е коректно в диапазона на действие на събитието:

SELECT * FROM articles;
+----+----------+-----------------------+--------+---------------------+
| id | title    | contents              | visits | last_visits_update  |
+----+----------+-----------------------+--------+---------------------+
|  1 | Статия 1 | Някакво съдържание... |      4 | 2012-04-03 15:23:45 |
|  2 | Статия 2 | Друго съдържание...   |      3 | 2012-04-03 15:23:45 |
+----+----------+-----------------------+--------+---------------------+
2 rows in set (0.00 sec)

-- след известно време...

SELECT * FROM articles;
+----+----------+-----------------------+--------+---------------------+
| id | title    | contents              | visits | last_visits_update  |
+----+----------+-----------------------+--------+---------------------+
|  1 | Статия 1 | Някакво съдържание... |      6 | 2012-04-03 15:28:45 |
|  2 | Статия 2 | Друго съдържание...   |      3 | 2012-04-03 15:28:45 |
+----+----------+-----------------------+--------+---------------------+
2 rows in set (0.00 sec)

Така пазим повече данни в таблиците (датите и времената), но за сметка на това броим по-малко редове на всяко обновяване.

Накрая да не забравим да направим събитие, което ще изчиства logs таблицата в края на всеки ден (в нея пазим колона “TIME”, т.е. тя ще е актуална само в рамките на текущия ден):

CREATE EVENT truncate_logs
ON SCHEDULE EVERY 1 DAY
STARTS TIMESTAMP '2012-04-03 00:00:00'
DO TRUNCATE TABLE logs;

Както виждате можем да правим събитията регулярни като “интервал от … започвайки от дадено време”. Именно затова се използва ключовата дума STARTS. Ако я нямаше, то събитието щеше да започне от текущата дата. Аналогично можем да задаваме крайна дата на събитие чрез ключова дума ENDS.

Пример 2: Ще създадем база данни със служители (employees), клиенти (customers) и продукти (products):

CREATE TABLE employees(
   id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   name VARCHAR(255) NOT NULL
)ENGINE = InnoDB;

INSERT INTO employees(name)
VALUES ("Petar"), ("Ivan"), ("Maria");

CREATE TABLE customers(
   id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   name VARCHAR(255) NOT NULL
)ENGINE = InnoDB;

INSERT INTO customers(name)
VALUES ("Todor"), ("Mihail"), ("Angelina"), ("Mariela");

CREATE TABLE products(
   id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   name VARCHAR(255) NOT NULL,
   price DECIMAL(5,2) NOT NULL
)ENGINE = InnoDB;

INSERT INTO products(name, price)
VALUES ("Отверки", 6.50), ("Чукове", 12.80);

Ще създадем таблица “дневни продажби” (dailysales), в която ще записваме кой служител на кой клиент какво е продал и в какво количество за даден ден:

CREATE TABLE dailysales(
   employee_id INT UNSIGNED NOT NULL,
   FOREIGN KEY (employee_id) REFERENCES employees(id),
   customer_id INT UNSIGNED NOT NULL,
   FOREIGN KEY (customer_id) REFERENCES customers(id),
   product_id INT UNSIGNED NOT NULL,
   FOREIGN KEY (product_id) REFERENCES products(id),
   quantity SMALLINT NOT NULL,
   at_date DATE NOT NULL,
   PRIMARY KEY(employee_id, customer_id, product_id, at_date)
)ENGINE=InnoDB;

INSERT INTO dailysales(employee_id, customer_id, product_id,
                       quantity, at_date)
VALUES (1, 3, 1, 3, 2012-04-02),
       (1, 3, 2, 1, 2012-04-02),
       (2, 1, 1, 4, 2012-04-02),
       (2, 2, 1, 1, 2012-04-02),
       (1, 1, 2, 1, 2012-04-03),
       (3, 4, 2, 1, 2012-04-03);

Сега искаме да направим таблица с обобщение за приходите получени от даден служител за даден ден. Тя може да изглежда по следния начин:

CREATE TABLE employees_income(
   employee_id INT UNSIGNED NOT NULL,
   FOREIGN KEY (employee_id) REFERENCES employees(id),
   at_date DATE NOT NULL,
   total_income DECIMAL(6,2),
   PRIMARY KEY(employee_id, at_date)
)ENGINE=InnoDB;

И да създадем регулярно дневно събитие, което ще обновява информацията в тази таблица:

CREATE EVENT daily_income_stats
ON SCHEDULE EVERY 1 DAY
STARTS TIMESTAMP '2012-04-03 00:01:30'
DO
INSERT IGNORE
INTO employees_income(employee_id, at_date, total_income)
SELECT dailysales.employee_id, dailysales.at_date,
       SUM(dailysales.quantity * products.price)
FROM dailysales JOIN products
     ON dailysales.product_id = products.id
GROUP BY dailysales.employee_id, dailysales.at_date;

Правим проверка:

SELECT * FROM employees_income;
Empty set (0.00 sec)

-- на следващия ден (в нашия случай 04-04)
-- събитието ще изчисли всичко

SELECT * FROM employees_income;
+-------------+------------+--------------+
| employee_id | at_date    | total_income |
+-------------+------------+--------------+
|           1 | 2012-04-02 |        32.30 |
|           1 | 2012-04-03 |        12.80 |
|           2 | 2012-04-02 |        32.50 |
|           3 | 2012-04-03 |        12.80 |
+-------------+------------+--------------+
4 rows in set (0.00 sec)

Можем да се досетим, че събитието не е направено оптимално. С всеки следващ ден ще имаме все повече и повече дублиращи се редове, които ще се пропускат (използваме INSERT IGNORE… заявка). Ние обаче всеки път пресмятаме сумата на парите за всеки един от тях! Затова горното събитие не е добро – с напредване на времето то ще работи все по-бавно и по-бавно. Затова можем да я оптимизираме така, че да пресмята събитията само от предишния ден, а другите (вече изчислени) да не ги изчислява отново:

DROP EVENT daily_income_stats;

DELETE FROM employees_income;

CREATE EVENT daily_income_stats
ON SCHEDULE EVERY 1 DAY
STARTS TIMESTAMP '2012-04-03 00:01:30'
DO
INSERT INTO employees_income(employee_id, at_date, total_income)
SELECT dailysales.employee_id,
       DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY),
       SUM(dailysales.quantity * products.price)
FROM dailysales JOIN products ON dailysales.product_id = products.id
WHERE dailysales.at_date = DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
GROUP BY dailysales.employee_id, dailysales.at_date;

Проверка:

SELECT * FROM employees_income;
Empty set (0.00 sec)

-- на следващия ден (в нашия случай 04-04)
-- събитието ще вмъкне общите приходи
-- само за 04-03 (предишния ден)

SELECT * FROM employees_income;
+-------------+------------+--------------+
| employee_id | at_date    | total_income |
+-------------+------------+--------------+
|           1 | 2012-04-03 |        12.80 |
|           3 | 2012-04-03 |        12.80 |
+-------------+------------+--------------+
4 rows in set (0.00 sec)

В случая се възползвахме от функцията DATE_SUB, която връща разликана между две дати. По-конкретно DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY) ни дава “вчера”.

* Нарочно стартирахме събитието в 00:01:30, а не в 00:00:00. Не е добра идея да създавате събития, които се изпълняват точно в полунощ, защото стандартно много други приложения може правят други такива и по този начин да създавате излишен “час пик” за сървъра. Винаги гледайте събитията ви да се разминават във времето.

Задача. В пример 2 ако някой служител не е направил никакви продажби в даден ден, то той ще липсва в отчета за него. Направете така, че id на такъв служител да се добавя, а неговия total_income да бъде или 0 или NULL (по ваш избор).

Пример 1: Нека покажем един пример – имаме елементарна таблица, в която записваме данните за потребители, каквато например използваме за примера за скрипт за автентикация в раздел ПТСК:

CREATE TABLE users(
 id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
 username VARCHAR(32) NOT NULL,
 password CHAR(64) NOT NULL
)ENGINE=InnoDB;

Искаме да направим ограничение върху потребителското име, а именно – да бъде между 4 и 32 символа. Горната граница е ясно определена от типа на полето – varchar(32). По подразбиране ако се опитате да вмъкнете повече информация от предвидената, то тя ще бъде отрязана до 32 символ и вмъкната по този начин, а заявката ще бъде успешна, но със съответния “warning” (станал е “truncate” на низа). Ако MySQL е настроен да работи в режим с включен “STRICT_ALL_TABLES” (прочетете повече за режимите на MYSQL), то ще се генерира грешка.

Долната граница обаче не е лимитирана по никакъв начин. Искаме да направим така, че да се генерира грешка ако се опитаме да вмъкнем потребителско име по-късо от 4 символа. Ето как можем да го направим с тригер в MySQL 5.5 (и евентуално по същия начин в по-новите версии):

DELIMITER //

CREATE TRIGGER username_min_length_check
BEFORE INSERT ON users FOR EACH ROW
BEGIN
 DECLARE errormsg VARCHAR(255);
 IF CHAR_LENGTH(NEW.username) < 4
 THEN SET errormsg = CONCAT("Username too short: ", NEW.username);
      SIGNAL SQLSTATE '45000' SET message_text = errormsg;
 END IF;
END//

DELIMITER ;

SQL State със стойност 45000 има смисъл като “unhandled user-defined exception”, което е правилно да се използва за такива случаи. Ето две пробни заявки, които показват, че тригерът работи както очаквахме:

mysql> INSERT INTO users(username, password)
    -> VALUES ("user123", SHA2("password", 256));
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO users(username, password)
    -> VALUES ("aa", SHA2("password", 256));
ERROR 1644 (45000): Username too short: aa

Разбира се по-добре ще бъде да валидирате данните в самото приложение и въобще да не изпълнявате заявката ако потребител се опитва да се регистрира с по-къс низ за username. Ако обаче нивата на сигурност го изискват, то може да си позволите двойна проверка.

Ако системата евентуално позволява промяна на потребителско име, то може да направите такъв тригер и за UPDATE заявки.

Внимание: С показания тригер при вмъкването на множество редове накуп ако дори само един от тях предизвика въпросната грешка, то тя ще важи за цялата заявка и нито един от редовете няма да бъде вмъкнат, дори някои от тях да отговарят на условието.

Пример 2: Нека имаме две таблици – отдели и служители. Между тях ще има две връзки. Едната ще има смисъл, че “даден служител работи в даден отдел”, а другата “даден служител е мениджър на даден отдел”:

CREATE TABLE departments(
 id TINYINT UNSIGNED PRIMARY KEY,
 name VARCHAR(255) NOT NULL UNIQUE,
 manager INT UNSIGNED NULL DEFAULT NULL UNIQUE
)ENGINE = InnoDB;

CREATE TABLE employees(
 id INT UNSIGNED PRIMARY KEY,
 name VARCHAR(255) NOT NULL,
 d_id TINYINT UNSIGNED,
 FOREIGN KEY (d_id) REFERENCES departments(id)
    ON DELETE CASCADE ON UPDATE CASCADE
)ENGINE = InnoDB;

Сега създаваме два тригера – един за INSERT и един за UPDATE заявки, в които проверяваме дали стойността на “manager” в таблица “departments” е валидна:

DELIMITER //

CREATE TRIGGER managercheck_insert
BEFORE INSERT ON departments FOR EACH ROW
BEGIN
  IF NEW.manager IS NOT NULL
     AND
     NEW.manager NOT IN (SELECT id
                         FROM employees
                         WHERE employees.d_id = NEW.id)
  THEN SIGNAL SQLSTATE '45000'
       SET message_text = "The manager must be employee from the department";
  END IF;
END//

CREATE TRIGGER managercheck_update
BEFORE UPDATE ON departments FOR EACH ROW
BEGIN
  IF NEW.manager IS NOT NULL
     AND
     NEW.manager NOT IN (SELECT employees.id
                         FROM employees
                         WHERE employees.d_id = NEW.id)
  THEN SIGNAL SQLSTATE '45000'
       SET message_text = "The manager must be employee from the department";
  END IF;
END//

DELIMITER ;

Вмъкваме примерни данни:

INSERT INTO departments (id, name, manager)
VALUES (1, "Support", NULL),
       (2, "Sales", NULL);

INSERT INTO employees(id, name, d_id)
VALUES (1, "Petar", 1),
       (2, "Ivan", 1),
       (3, "Maria", 2);

И изпробваме дали тригерите работят:

mysql> UPDATE departments
    -> SET manager = 2
    -> WHERE id = 1;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

mysql> UPDATE departments
    -> SET manager = 3
    -> WHERE id = 1;
ERROR 1644 (45000): The manager must be employee from the same department

mysql> INSERT INTO departments(id, name, manager)
    -> VALUES (3, "Billing", 2);
ERROR 1644 (45000): The manager must be employee from the same department

Забележете, че по този начин дори не се налага да правим колоната “manager” като foreign key към employees. В действителност написаният тригер припокрива тази функционалност. Ето какво ще се случи ако се опитаме да въведем несъществуваща стойност в тази колона:

mysql> INSERT INTO departments(id, name, manager)
    -> VALUES (3, "Billing", 12);
ERROR 1644 (45000): The manager must be employee from the same department