mc powrot do powloki

CTRL + O
; )

Vim commenting

Jak zakomentować zaznaczony tekst w vimie ?

1.ctrl+v (tryb visual)
2.j lub down arrow zaznaczamy text
3.shift+i (tryb insert)
4.wpisuje dowolny znak (w tym przypadku #)
5.klepiemy dwa razy [Esc]
6.Tada ! ; )

Mysql Events

Kiedys o tym slyszalem ale ucichlo.
Nie mniej temat dobrze rokuje a zatem :
Pierw configuracja :

SET GLOBAL event_scheduler = 1/0 (ON/OFF)

Mozna tez dopisac na stałe do configu.

Tabela testowa:

CREATE TABLE zdarzenia_test (
  id int(10) NOT NULL AUTO_INCREMENT,
  data timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`)
) ENGINE=MyISAM

oraz event który będzie wrzucał co 10s wpis :

CREATE EVENT event_first_test ON SCHEDULE EVERY 10 SECOND DO insert into zdarzenia_set set data=now()

wszystko smiga :

mysql> select * from zdarzenia_test order by data desc limit 3;
+-----+---------------------+
| id  | data                |
+-----+---------------------+
| 209 | 2011-12-26 12:22:53 |
| 208 | 2011-12-26 12:22:43 |
| 207 | 2011-12-26 12:22:33 |
+-----+---------------------+
3 rows in set (0.00 sec)

Dobra ale co gdy jakaś akcja się nie uda ?

mysql> drop table zdarzenia_test;
Query OK, 0 rows affected (0.00 sec)

Informacja idzie do error loga :

111226 12:24:33 [ERROR] Event Scheduler: [root@localhost][test.event_first_test] Table 'test.zdarzenia_test' doesn't exist
111226 12:24:33 [Note] Event Scheduler: [root@localhost].[test.event_first_test] event execution failed.

Wszystko fajnie tyle, tylko pewnie nie kazdy lubi sobie czytac error loga wieczorami; )
Zdecydowanie brakuje jakieś możliwosci w stylu wyslij maila (cos na wzor schedule'ra w MSSQL).
Oczywiscie mozemy sobie to jakos obsluzyc skryptowo ale przydałaby sie jakas funkcja systemowa.
Nie mniej jednak sam feature jest dosyc fajny. Nie sadze, zeby szybko zastąpił skrypt w cronie jednak do przeliczania
nie krytycznych danych,czyszczenia tabel nadaje się idealnie.
Oczywiscie to tylko zarys. Istnieje dużo więcej możliwosci konfiguracji (data startu,zakonczenia etc)
Zachęcam do lektury ; )
http://dev.mysql.com/doc/refman/5.1/en/alter-event.html

mysql to csv

Zawsze zapominam:

select m.kierunkowy,p.prefix,vn.callerid,vn.typ 
INTO OUTFILE '/tmp/numery.csv' 
FIELDS TERMINATED BY ';' 
LINES TERMINATED BY '\n' 
from s3_oss.voip_numery vn 
join s3_oss.prefix p on (p.prefix=vn.prefix) 
join s3_teren.miasta m on (m.id_miasta=p.id_miasta) 
where p.id_miasta=9 and p.aktywny=1 and p.typ_prefixu='normalne' and p.id_typu_numeru=1 
order by vn.callerid;

mysql views

Jak sprawdzic kto ma prawa do danej procedury, tabeli w mysql ?
Ano tak :

dla tabelki:

select * from mysql.tables_priv where Table_name='vip';

dla kolumny :

select * from mysql.columns_priv where Table_name='NET' and column_name='new';

dla procedury/funkcji :

select * from mysql.procs_priv where Routine_name='show_stats' ; 

Oczywiscie mozemy filtrować po dowolnej kolumnie danego widoku ; )

Distinct vs group by

Miałem dziś w pracy małą zagwozdkę.
Mianowicie serwer zaczał się dusić przy pewnym zapytaniu. Po modyfikacji skryptu udało mi się końcowe zapytnie ograniczyć do

mysql> select count(*) from kontrakty;
+----------+
| count(*) |
+----------+
|   224407 | 
+----------+

mysql> select count(*) from users;
+----------+
| count(*) |
+----------+
|      630 | 
+----------+

select sql_no_cache distinct CONCAT(u.nazwisko,' ',u.imie) from kontrakty sk  join users u on (u.id_user=sk.id_user_realizacja)  order by nazwisko,imie;
91 rows in set (0.85 sec)

Niby fajnie czas spadł z ~4s do 0.85s ale ciągle wydawało mi się to zbyt długo.
Z czytania describe''a jestem cienki jak polsilver:

mysql> desc select sql_no_cache distinct CONCAT(u.nazwisko,' ',u.imie) from kontrakty sk  join sers u on (u.id_user=sk.id_user_realizacja)  order by nazwisko,imie; 
+----+-------------+-------+--------+----------------------------------------+---------------------+---------+---------------------------------+--------+----------------------------------------------+
| id | select_type | table | type   | possible_keys                          | key                 | key_len | ref                             | rows   | Extra                                        |
+----+-------------+-------+--------+----------------------------------------+---------------------+---------+---------------------------------+--------+----------------------------------------------+
|  1 | SIMPLE      | sk    | index  | skontrakty_FKIndex3,id_user_realizacja | skontrakty_FKIndex3 | 4       | NULL                            | 217875 | Using index; Using temporary; Using filesort | 
|  1 | SIMPLE      | u     | eq_ref | PRIMARY                                | PRIMARY             | 4       | sk.id_user_realizacja |      1 |                                              | 
+----+-------------+-------+--------+----------------------------------------+---------------------+---------+---------------------------------+--------+----------------------------------------------+

Trochę pokombinowałem i nagle wpadłem na pomysł, zeby użyć group by. Efekt był pozytywnie zaskakujący : 91 rows in set (0.12 sec)

mysql> desc select sql_no_cache CONCAT(u.nazwisko,' ',u.imie) from kontrakty sk  join users u on (u.id_user=sk.id_user_realizacja)  group by u.id_user order by nazwisko,imie;
+----+-------------+-------+-------+----------------------------------------+--------------------+---------+--------------------+------+---------------------------------+
| id | select_type | table | type  | possible_keys                          | key                | key_len | ref                | rows | Extra                           |
+----+-------------+-------+-------+----------------------------------------+--------------------+---------+--------------------+------+---------------------------------+
|  1 | SIMPLE      | u     | index | PRIMARY                                | PRIMARY            | 4       | NULL               |  763 | Using temporary; Using filesort | 
|  1 | SIMPLE      | sk    | ref   | kontrakty_FKIndex3,id_user_realizacja | id_user_realizacja | 4       | u.id_user |  660 | Using index                     | 
+----+-------------+-------+-------+----------------------------------------+--------------------+---------+--------------------+------+---------------------------------+

Nie ma aż takiego szału ale patrząc na całość (4s->0.12s) to jestem zadowolony.
Jak na razie nie jestem w stanie powiedzieć czemu group by zadziałało szybciej ale w najbliższych planach mam nauczynie czytania się desc'a ;]

grep exclude-dir

Kiedy potrzebowałem przegrepować się w poszukiwaniu jakiegoś wzorca przeważnie używałem :

grep -r 'search_pattern' * | grep -v 'nazwa_katalogu'

CO jednak powodowało duzo wieksze uzycie cpu.
Grep bodajze od wersji 2.5 oferuje fajny parametr --exclude-dir:
To samo po nowemu:

grep  --exclude-dir='nazwa_katalogu/*' -r 'search_pattern' *

Jesli jeszcze chcemy pozbyć się jakis plików (np pdf) dodajemy :

grep  --exclude-dir='nazwa_katalogu/*' --exclude='*.pdf' -r 'search_pattern' *

key_buffer_size oraz myisam_sort_buffer_size

Idąc za ciosem doczytałem się jeszcze o dwóch zmiennych

key_buffer_size

The key_buffer_size is probably the most useful single variable to tweak. The larger you set it, the more of your MyISAM table indexes you store in memory. With most queries making use of an index, and memory being an order of magnitude faster than disk, the importance of this variable cannot be overestimated.
On dedicated MySQL servers, the rule-of-thumb is to aim to set the key_buffer_size to at least a quarter, but no more than half, of the total amount of memory on the server. Ideally, it will be large enough to contain all the indexes (the total size of all .MYI files on the server)


myisam_sort_buffer_size
used as buffer when alter table & myisam sorting is req. 

Z testow wynika, ze drugi parametr jest mniej istotny.
W kazdym razie wartosci zostaly zmieniony z
key_buffer_size - z 512MB na 1 i 2 GB
myisam_sort_buffer_size - z 8MB na 256MB
4 GB pamięci na serwerze

1.myisam_max_sort_file_size=10G key_buffer_size=1GB myisam_sort_buffer_size=256 MB

mysql> insert into historia_test2 select NULL,PK_nazwa,PK_wartosc,data_transakcji,typ_trasakcji,opis,id_user from historia;
Query OK, 4555320 rows affected (39.38 sec)
Records: 4555320  Duplicates: 0  Warnings: 0

mysql> insert into historia_test2 select NULL,PK_nazwa,PK_wartosc,data_transakcji,typ_trasakcji,opis,id_user from historia;
Query OK, 4555320 rows affected (43.46 sec)
Records: 4555320  Duplicates: 0  Warnings: 0

mysql> alter table historia_test2 enable keys;
Query OK, 0 rows affected (2 min 2.44 sec)

2.myisam_max_sort_file_size=10G key_buffer_size=2GB myisam_sort_buffer_size=256 MB

mysql> insert into historia_test2 select NULL,PK_nazwa,PK_wartosc,data_transakcji,typ_trasakcji,opis,id_user from historia;
Query OK, 4555320 rows affected (40.78 sec)
Records: 4555320  Duplicates: 0  Warnings: 0

mysql> insert into historia_test2 select NULL,PK_nazwa,PK_wartosc,data_transakcji,typ_trasakcji,opis,id_user from historia;
Query OK, 4555320 rows affected (43.70 sec)
Records: 4555320  Duplicates: 0  Warnings: 0

mysql> alter table historia_test2 enable keys;
Query OK, 0 rows affected (1 min 56.42 sec)

Jak widać zarówno na insertach jak i odbudowie indexow udało sie jeszcze urwać parę sekund ;)

myisam_max_sort_file_size

Ostatnio musiałem utworzyć troche większe źródła danych tak aby przetestować partycjonowanie danych.
Do testów poszła tabela trzymajaca dane historyczne zawierajaca

id              | int(10) unsigned |
PK_nazwa        | varchar(255)     |
PK_wartosc      | varchar(255)
data_transakcji | timestamp
typ_trasakcji   | enum('insert','update','delete','replace') 
opis            | text 
id_user         | int(10) unsigned 

Aby się za bardzo nie wysilać postanowiłem powielić dane w tabelii. (początkowo miała ok 4,5 mln rekordów)

mysql> insert into historia_test select NULL,PK_nazwa,PK_wartosc,data_transakcji,typ_trasakcji,opis,id_user from historia;
Query OK, 4555320 rows affected (2 min 3.99 sec)
Records: 4555320  Duplicates: 0  Warnings: 0

mysql> insert into historia_test select NULL,PK_nazwa,PK_wartosc,data_transakcji,typ_trasakcji,opis,id_user from historia;
Query OK, 4555320 rows affected (5 min 41.65 sec)
Records: 4555320  Duplicates: 0  Warnings: 0

Jak widać za każdym razem dodawanie nowych danych zabierało więcej czasu. Przy przejściu z 13,5 mln na 18 wynosiło to prawie 12 min.
Do testów potrzebowałem tabeli z ok 30 mln. Tak więc kolejne powielanie by mnie zabiło.
Googlując dokopałem się do informacji , ze przy wszelkich bulk insertach dobrze jest wyłączyc indeksowanie na tabeli.

mysql> alter table historia_test2 disable keys;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into historia_test2 select NULL,PK_nazwa,PK_wartosc,data_transakcji,typ_trasakcji,opis,id_user from historia;
Query OK, 4555320 rows affected (42.13 sec)
Records: 4555320  Duplicates: 0  Warnings: 0

mysql> insert into historia_test2 select NULL,PK_nazwa,PK_wartosc,data_transakcji,typ_trasakcji,opis,id_user from historia;
Query OK, 4555320 rows affected (40.27 sec)
Records: 4555320  Duplicates: 0  Warnings: 0

Spadek z 5min na 40s wygląda całkiem ok ;)
No to włączamy spowrotem indeksowanie:

mysql> alter table historia_test2 enable keys;
Query OK, 0 rows affected (15 min 33.28 sec)

Czas mnie zabił...

mysql> show processlist;
+-----+------+-----------+------+---------+------+----------------------+----------------------------------------+
| Id  | User | Host      | db   | Command | Time | State                | Info                                   |
+-----+------+-----------+------+---------+------+----------------------+----------------------------------------+
| 157 | root | localhost | test | Query   |  897 | Repair with keycache | alter table historia_test2 enable keys |
+-----+------+-----------+------+---------+------+----------------------+----------------------------------------+

Na googlach doszukałem się informacji o zmiennej : myisam_max_sort_file_size

MYISAM_MAX_SORT_FILE_SIZE sets the maximum size of the temporary file that MySQL is allowed to use while re-creating a MyISAM index (during REPAIR TABLE, ALTER TABLE, or LOAD DATA INFILE). If the file size would be larger than this value, the index is created using the key cache instead, which is slower. The value is given in bytes and the default value is 2GB. 
Set this values a bit larger thatn the largest index file if there is disk space is available to ensure that REPAIR TABLE is be done by sort rather than repair by key cache. Sorting is much faster than repair by key cache.

No to zmieniamy:
Początkowo było 2 GB:

mysql> show variables like '%myisam_max_sort_file_size%' ;
+---------------------------+------------+
| Variable_name             | Value      |
+---------------------------+------------+
| myisam_max_sort_file_size | 2146435072 |
+---------------------------+------------+

Do my.cnf poleciał wpis :
myisam_max_sort_file_size=10G

mysql> show variables like '%myisam_max_sort_file_size%' ;
+---------------------------+-------------+
| Variable_name             | Value       |
+---------------------------+-------------+
| myisam_max_sort_file_size | 10737418240 |
+---------------------------+-------------+

Powrótka z operacji,stworzenie tabelki,wylaczenie indeksowania,inserty,wlaczanie indeksow.

mysql> alter table historia_test2 enable keys;

Query OK, 0 rows affected (2 min 23.04 sec)
Spadek z 15 min na 2.23 brzmi bardzo ok :)

mysql> show processlist;
+-----+------+-----------+------+---------+------+-------------------+----------------------------------------+
| Id  | User | Host      | db   | Command | Time | State             | Info                                   |
+-----+------+-----------+------+---------+------+-------------------+----------------------------------------+
| 154 | root | localhost | test | Query   |  261 | Repair by sorting | alter table historia_test2 enable keys |
+-----+------+-----------+------+---------+------+-------------------+----------------------------------------+

Pierwszy

trololo

damn