codez

Sliktajam: 1, 'SIMPLE', 'geo_block', 'range', 'PRIMARY', 'PRIMARY', '4', '', 1471555, 'Using where' Labajam: 1, 'SIMPLE', 'geo_block', 'range', 'PRIMARY', 'PRIMARY', '4', '', 1471555, 'Using where' Šeit jau tas āķis, ka EXPLAIN abiem ir vienāds, šeit vairāk tiek izmantots tas, ka es zinu kāda ir šī tabula un zinu, ka man vajadzīgais ieraksts, būs pēdējais, kuram ip1<=userip. Pat, ja pirmajam pieliek LIMIT 1 tas ir nemainīs būtību, jo ieraksts tiks atrast kā pēdējais no pārbaudāmajiem ierakstiem, bet otrajam LIMIT 1 ir vajadzīgs, jo mysql atradīs man vajadzīgo rowu kā pirmo, bet turpinās meklēt vēl rowus, lai gan tādus vairs nav, bet viņš to nezin, jo redz, ka ir vēl kaudze ierakstu kuriem ip1<=userip. EDIT: tabulas lauki ir: ip1 ip2 locid, userip ir lietotāja ip adrese, kuras locid es vēlos atrast. Šeit nav sākot un beidzot, jo ir divi fieldi ip1 un ip2, kur vienam mēs norādam ip1<=userip, tātad no pirmā ieraksts līdz userip, otram savukārt no userip līdz beigām. Bet binārais koks nevar divu fieldu intervālus apskatīt kā šijā brīdī tas indutīvi varētu šķist.

Nedaudz patestēju, patiesībā, ja ieliek pēdējo ip vērtību sliktajā kverijā viss izpildās diezgan ātri, jo tad acīmredzot mysql apstaigā koku no otras puses. Visilgāk kverijs izpildās, ja no 3miljoni vērtībām, ieliek 1,5 miljono. Tad sliktā kverija izpildes laiks 1,5 s, savukārt labā kverija izpildes laiks 9 ms.

Binārais koks no līdz intervālu var paņemt tikai uz vienu lauku, bet šeit ir divi lauki ip1 un ip2. Lai paņemtu no līdz uz diviem, tad ir jāizmanto SPATIAL index, bet šajā gadījumā tā būtu lieka ķēpa.

LIMIT 1 šeit nav atslēgas frāze Sliktais kverijs: SELECT locid FROM geoip WHERE ip1<=userip AND ip2>=userip LIMIT 1 ; Labais kverijs: SELECT locid FROM geoip WHERE ip1<=userip AND ip2>=userip ORDER BY ip1 DESC LIMIT 1 ; Lai saprastu atšķirību starp šiem jasaprot kā mysql izmanto indeksu. Tā kā šijā gadījumā indeks bija PRIMARY KEY uz ip1 ip2 un indeksa tips binary tree. ja mēs userip izvēlamies tādu, kas atbilst pēdējam ierakstam, tad 1. kverijā nosacījums ip1<=userip izpildās pilnīgi visiem ierakstiem un mysql datu bāzei ir jāapskata pilnīgi visi ieraksti, lai pārbaudītu katram arī atbilstošo ip2. Taču mums vienmēr ir vajadzīgs pēdējais ieaksts, kurš atbilst šim nosacījumam, tāpēc mēs vienkārši pieliekam ORDER BY ip1 DESC, lai mysql sāk meklēt no pēdējā vajadzīgā ieraksta, kurš arī būs mums nepieciešamais ieraksts un 2. gadījumā tiks apskatīts tikai 1 ieraksts, kurš tiks atgriezts.

ip formāts integer

Ar js izveido masīvu, kurā glabāsies izvēlētie objekti. Kad nospiež uz kategorijas ar ajax ielādē kategorijas sarakstu. Kad nospiež pievienot kādu lietu ar ajaxu aizsūta ka lieta tiek pievienota un sessijās saglabā, tad pēc tās lietas id pievieno js masīvam un tāpat arī lietu vizuāli ievieto attēlošanai Kad nospiež lietu izdzēst ar ajaxu aizsūta un no sesijas izdzēš lietu, tad pēc lietas id izdzēš to no js masīva, kā arī izdžēš tās attēlojumu. Var arī js masīvu netaisīt, bet pēc lietas pievienošanas un lietas izdzēšanas no servera atsūtīt sarakstu ar visām pievienotajām lietām un tad veikt tā attēlošanu.

Kā jau pēc konteksta varēja noprast, šis kverijs ir nepareizs, jo, ja mēs userip ieliekam tabulas pēdējo, pēc ip1 lielāko ip adresi, tad salīdzinošā darbība userip>=ip1 izpildās pie katra no 3 miljoni ierakstiem un patiesībā datubāze apskata katru ierakstu un index šeit nekādi nepalīdz. Pareizs kverijs būtu, ja mēs meklētu pēdējo ip1, kurš ir mazāks par userip, tad ar indexa palīdzību, tiek apskatīts tikai viens rows: SELECT locid FROM geoip WHERE ip1<=userip AND ip2>=userip ORDER BY ip1 DESC LIMIT 1 ; Ar šo piermēru gribēju parādīt, ka koda izpildes un kveriju laiku mērīšana atmaksājās, jo uzlabot kveriju prasīja pāris minūtes, bet reālāis skaitļošanas resursu ietaipījums ir salīdzinoši liels. Šijā gadījumā šis kverijs tērēja vairāk skaitļošanas resursu, kā viss pārējais tās lapas ģenerēšanas kods kopā.

andrisp, paldies par komplimentiem, liekas, ka arī tu esi starp tiem, kuri spēj anonīmā vidē apvainoties uz virtuāliem tēliem. cheers! Īsti gan neatceros, kad kādu būtu saucis par ideotu, bet viss var gadīties. Bet katrā ziņā, ja es pasaku kādam, ka viņš ir ideots un viņu tas aizskar, tad kompleksi ir viņam, nevis man. P.S. Vēl esmu novērojis, ka šajā forumā dažiem ir smagas problēmas ar humora izjūtu. Džeki, nepalieciet par nūģiem, ja joks nepatika, neiespringstiet.

Piemērs no dzīves: IP datubāze ar 3 miljoni ierakstiem tabula geoip: ip1 INTEGER ip2 INTEGER locid INTEGER primary key uz ip1 Cilvēks uzraksta kveriju: SELECT locid FROM geoip WHERE userip>=ip1 AND userip<=ip2 Cilvēkam nebija pilnīga izpratne par indeksu darbību. Taču šīs analīzes sistēmas uzreiz parādīja, ka kverijs tiek pildīts 0.15 s. Šāds kverijs lieki tērētu gan db skaitļošanas resursu, gan lapas ielādes laiks paliktu nedaudz lielāks, taču ar aci vēl nebūtu pamanāms.

Manuprāt neslikt variants ir izmantot parastu masīvu un vajadzības gadījumā inclūdot, jo php masīva nolasīšana būs ātrākā kā griešānās pie db. config.php <?php return array( "time_zone"=>2, "limit"=>1000 ) $config=require_once('config.php'); echo $config['time_zone']; Kaut kā tā

He,he, nabaga emocionāli aizskartie bērnudārznieki. Kad apdirst par manuāļu nelasīšanu vai tēlot apvainotos un piesārņot topiku, tad baigie varoņi, kā pasaka pāris skarbus vārdus pretī, tā apvainojas kā tādas primadonnas vai pirmskolas vecuma bērni un sāk normālus topikus pārvietot un drazu. Varu pateikt jums ka, kamēr nespēsiet izkāpt no savas bērnudārza vecuma attieksmes, tikmēr pilnā krāšņumā izpaudīsies jūsu psiholoģiska rakstura problēmas.

Bet jautājums jau paliek, kā tu nosaki ka lapa bremzē? Uz aci? Es uzskatu, ka lapa jau ir bremzīga, ja tā tiek ģenerēta virs 300ms, bet ar aci grūti būs atšķirt, vai tev lapu ģenerē 350ms vai 50ms.

Kādus darba efektivitātes tūļus izmantojat, lai analizētu sava koda perfomanci un spētu uzlabot tā ātrdarbību? Padalieties ar info, varbūt parādīsies, kas neredzēts. Es izmantoju: 1)Xdebug - debugošanai un PHP profilingam http://www.xdebug.org/ + Webisku profilinga informācijas apskati http://code.google.com/p/webgrind/ 2)Mysql iebūvēto profileri. http://dev.mysql.com/tech-resources/articl...y-profiler.html 3)Individuālus kverijus analizēju ar EXPLAIN, lai redzētu vai indeksi ir salikti kā vajag un vai kverijs kaut kur nav efektīvs. http://dev.mysql.com/doc/refman/5.1/en/using-explain.html Varbūt ir vēl kaut kas efektīvs, ko varētu izmantot?

Options +FollowSymlinks RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*) index.php?path=$1 [QSA,L] Parasti man .htaccess fails izskatās šāds un tad ar explode("/", $_GET['path']); iegūst masīvu ar visām tevi interesējošām vērtībām. Kā $_GETā uzreiz dabūt, uzreiz nepateikšu.

Vai var UPDATE un DELETE izpildīt vienā kverijā? It kā pēc loģikas jau būtu baigi forši, mēs SELECTOJAM vienu ROWU ar kura datus izmantojam cita updeitošanai un tad to ROWu izdzēšam. Ja taisa atsevišķi, tad MYSQLam sanāk divas reizes meklēt vienu un to pašu ROWu un tas reāli iebremzē manu super duper pelnošo portālu.

bubu, kamēr tu pārlasi kārtējo manuāli, es jau esmu uztaisījis pusi megapeļņu nesoša portāla, kad rodas kāda aizture, tad pameklēju webā vai paprasu forumā, kamēr citi atbild (paldies viņiem par to), tikmēr taisu citas lietas, kur man aizķeršanās nav. Kad atbilde iegūta, turpinu iepriekšējo. Paies pāris mēneši un es būšu uztaisījis super giga mega piķi pelnošo portālu (to vajag uztvert labi), bet tu būsi izlasījis 37 manuāļus un 14 grāmatas "čainikiem" (to arī vajag uztvert labi, jo savādāk jau nebūs neviens, kurš atbild uz maniem jautājumiem). Tad redzēsim, kurš priecāsies pēdējais.

Lasi Mārtiņ visas "tējkannu" grāmatas pēc kārtas, ja tev citu nav ko darīt, es tikmēr pelnīšu mega lielo piķi, sasniedzot rezultātu pēc iespējas ātrāk. P.S. Lai tu pierādītu ka neesi kārtējais "programmētājs", gaidu tavu 100% risinājumu šim uzdevumam: http://www.lio.lv/olimps/uzdevumi.php?show=20

O, tieši tas ko man vajag, nekad nebiju izmantojis UPDATEā references uz vairākām tabulām, tāpēc neināca pat prātā, ka tā var. Gintam paldies.

Ir tabula: id v1 v2 v3 v4 v5 v6 ... v20 Izvēloties divus id, vajag abus rowu v1-v20 vērtības salikt pirmajā rowā sasummējot. Piemēram: 1 10 10 20 20 ..... 2 15 30 15 30 ..... izpildām "maģisko" kveriju, paliek: 1 25 40 35 50 ...... Vai kādam nav ideja, kā šādu darbību veikt vienā kverijā? (otrā rowa izdzēšana var būt atsevišķs kverijs)

Klase nevar būt skice, jo PHP klases metodes var izmantot abstraktā veidā, bez instances.

Visdrīzāk tur, kur jābūt masīvam, nav masīvs.

Ja izvadē tikai vajag, tad ar: http://lv.php.net/number-format

Tākā JAVA to visdrīzāk nezin, jo nav atbildējis, tad pateikšu kā var dabūt vairākus SELECTU datus no viena CALL kverija: http://lv2.php.net/manual/en/mysqli.use-result.php <?php $mysqli = new mysqli("localhost", "my_user", "my_password", "world"); /* check connection */ if (mysqli_connect_errno()) { printf("Connect failed: %s\n", mysqli_connect_error()); exit(); } $query = "SELECT CURRENT_USER();"; $query .= "SELECT Name FROM City ORDER BY ID LIMIT 20, 5"; /* execute multi query */ if ($mysqli->multi_query($query)) { do { /* store first result set */ if ($result = $mysqli->use_result()) { while ($row = $result->fetch_row()) { printf("%s\n", $row[0]); } $result->close(); } /* print divider */ if ($mysqli->more_results()) { printf("-----------------\n"); } } while ($mysqli->next_result()); } /* close connection */ $mysqli->close(); ?>

Tu vienā pieprasījumā tā vai tā vairāk par 1 bildi izvadīt nevari.

Tad jau var html kodā paslēpt flash objektu, kurā iebūvē mysql konektēšanās funkcijas un ar jūzeri, kurš var tikai izsaukt procedūras, izsauc un dabū datus. PHP pat nebūs vajadzīgs vipār. Ielādēsi pliku HTML ar paslēptu Flashu un datus no DB caur tiešo Flash-Mysql konekciju. Vai nav jauki? :)