MySQL -- ORDRER BY

[KtK]

Jak mam donutit mysql k nasledujicimu:

Kdyz dam

SELECT .... ORDER BY pozlozka1, polozka2;

tak mi to sice seradi podle polozky1 a 2, ale abecedne, a to i kdyz jsou obe polozky typu INT. Ja to ale chci seradit cislene. Co s tim? ThX, KtK.

[Wohmatak]

a jsou ty pole jako INT? nejsou nahodou varchar? pokud jeden z tech sloupcu bude string-ova promenna tak se to bude radit abecedne
pokud budou vsecky int tak by to melo byt dle velikosti cisla

[KtK]

vsechny (oba) jsou int. Ale nacpaval jsem je tam funkcema, ktery vraci string, ale to snad nevadi, ne, kdyz jsou deklarovany jako string..?
mysql> show fields from DNS_usr_pass;

sleduj:

+--------+--------------+------+-----+---------+-------+
| Field  | Type         | Null | Key | Default | Extra |
+--------+--------------+------+-----+---------+-------+
| ip     | varchar(15)  |      | PRI |         |       |
| domain | varchar(255) |      |     |         |       |
| user   | varchar(255) |      |     |         |       |
| pass   | varchar(255) |      |     |         |       |
| IPlev2 | int(11)      |      |     | 0       |       |
| IPlev3 | int(11)      |      |     | 0       |       |
| end3   | varchar(11)  |      |     |         |       |
| end2   | varchar(7)   |      |     |         |       |
| end1   | char(3)      |      |     |         |       |
+--------+--------------+------+-----+---------+-------+
9 rows in set (0.00 sec)

mysql> select IP, IPlev2, IPlev3 from DNS_usr_pass WHERE 1 ORDER BY IPlev2, IPlev3 LIMIT 20;
+--------------+--------+--------+
| IP           | IPlev2 | IPlev3 |
+--------------+--------+--------+
| 147.32.0.0   |      0 |      0 |
| 147.32.0.1   |      0 |      1 |
| 147.32.0.2   |      0 |      2 |
| 147.32.0.3   |      0 |      3 |
| 147.32.0.4   |      0 |      4 |
| 147.32.0.5   |      0 |      5 |
| 147.32.0.6   |      0 |      6 |
| 147.32.0.7   |      0 |      7 |
| 147.32.0.8   |      0 |      8 |
| 147.32.0.9   |      0 |      9 |
| 147.32.0.109 |      0 |     10 |
| 147.32.0.108 |      0 |     10 |
| 147.32.0.107 |      0 |     10 |
| 147.32.0.106 |      0 |     10 |
| 147.32.0.105 |      0 |     10 |
| 147.32.0.104 |      0 |     10 |
| 147.32.0.103 |      0 |     10 |
| 147.32.0.102 |      0 |     10 |
| 147.32.0.101 |      0 |     10 |
| 147.32.0.100 |      0 |     10 |
+--------------+--------+--------+
20 rows in set (0.29 sec)

EDIT: Jaj, jsem debil, vidim, ze to mam cely spatne.. sorry..

[Wohmatak]

Jenze IPLev3 je u tech poslednich stejnej, takze se to zacne radit podle IP.. apropo proc neni IP jako int? zkus dat IP jako int a myslim ze to bude fachcit (mysql povoluje v ciselnicych vyrazech tecku, ne? )

[AjsTi]

select * from blala order by blaba;
No mozno som Ti pomohol

[KtK]

IPlev3 mela byt posledni cast IP, IPle2 predposledni. jenze neni - je 10 tam, kde ma byt 10X - nekam se ztratilo posledni cislo, musim tu tabulku prestavet, pak se uvidi.. Razeni podle IP by asi moc nevyresilo -

0.0.10.0 by asi bylo totez jako 0.0.0.100 a nebylo by problem takhle zpusobit dokonce otoceni poradi.. Nebo ja nevim, jak se pak interpretuje takovy retezec..

AjTsi: diky, moc jsi mi pomohl..

[Wohmatak]

NEEE ja myslel dat IP jako int a davat
select * from DNS_usr_pass order by IPLEV2,IPLEV3, IP

pak by se ty posledni s IPLEV3 radily podle IP, coz je spravne (za predpokladu ze IP bude int)

tak napred vyres proc to dela 10 misto 10x...

[KtK]

Jasne, mam ted skolu, takze na to mrknu vecer. ty IPlev-y jsem stoural z IP pres mysql funkci myslim POSITION() a SUBSTRING(), asi nakej chybnej parametr...

KtK.

[KtK]

Tak jsem to opravil, uz to bezi bez problemu..

[KtK]

Dotazek: Jak myslite, ze se bude mysql tvarit na 500MB db? Bude se mu s tim chtit pracovat? (na mym stroji..) Asi to moc slavny nebude, co?

[Glottis]

pojede to. ale chce to dost pameti asi uz a rychle disky ale jet by to melo. pak rekni jak to jde to me zajima

[KtK]

No zatim sbiram data, a mozna to nebude tak horky, delal jsem ten odhad na zaklade malyho vzorku dat.. Ted to vypada tak na 300MB ale porad se to muze vyrazne zmenit obema smery.. Premyslim, jestli by to pak urychlila, nebo zpomalila transparentni komprese, v ty db se bohuzel dost opakujou nektery retezce.. - to by snad znamenalo, ze ta komprese nebude az tak obtizna.

[KtK]

No, tak DB ma zatim nakych 90MB. Vyhledavani je neunosne pomaly (~10s), pokud tam nejsou indexy.
potrebuju vyhledavat v jedny polozce, co je varchar(255). Kdyz dam vytvort FULLTEXT index, tak se to pri vyhledavani pres MATCH() AGAINST() zrychli na hodnoty, ktery jsou naprosto v poho.
Kdyz vytvorim obyc. INDEX, tak to vyhledava velmi rychle dotazy typu LIKE 'neco%';
Muj problem je, ze potrebuju vyhledavat ...LIKE '%neco%'; Takze obyc, index je mi malo platnej a vyhledavani pres MATCH AGINST myn pozadavkum taky neodpovida.. Nejaky navrhy reseni? Docela me to trapi, ze to nejde.. nechci se spokojit s tim MATCH() AGAINST();

EDIT: jestli nabizi postgres naky efektivnejsi zaindexovani, tak bych to mohl presunout i na postgres..