Witam

Przykładowo posiadam takie zapytanie:

[SQL] pobierz, plaintext 
SELECT * FROM newsy WHERE activ=1 ORDER BY id DESC
[SQL] pobierz, plaintext 

pobierane są nim najnowsze, aktywne newsy. Czy jest sens nakładania indeksów dla activ, gdzie wartość INT jest równa 0 lub 1? Czy to ma sens?

hmm może zaśmiecam ale skoro wartość jest albo 0 albo 1 WYDAJE mi się żeby typ pola był tinyint

nie zastanawiałem się nad tym, zwykle stosuję INT w przypadku cyfr. Czy w takim przypadku, gdzie mam wartość 0 lub 1 warto zastosować tinyint? Odbije się to w stosunku do wydajności?

a o czymś takim jak bool nie słyszeli panowie?

Ale bool w MySQL jest synonimem TINYINT(1), o ile pamiętam.


A użyj explain, to się dowiesz.

Nie używałem nigdy explain, lecz wydaje mi się, że używa się tego z poziomu linii komend mysql (a niestety do konsoli myslq nie mam dostępu). Szkoda mi teraz eksperymentować i bawić się z tym, gdyż wolałbym skorzystać z doświadczenia użytkowników forum, którzy mogą odpowiedzieć na mój problem jednym słowem. W dalszym ciągu prosiłbym o jasną odpowiedź, czy dla tinyiny(1) warto nakładać indeksy?

Nie.

dziękuję

Mylisz się. Nawet phpMyAdmin ma stosownego linka do wywołania tego zapytania.

Zresztą, poszukałbyś, to by Ci się nie wydawało i miałbyś odpowiedź na tacy.

A co do zasadności umieszczania indeksu, to byłbym innego zdania.

Innego, czyli że warto takowy indeks zbudować? To może ja rozwinę swoją wypowiedź "Nie". Według mnie nie warto dawać na tą kolumnę indeksu ponieważ ma bardzo małe zróżnicowanie przyjmowanych wartości (0 lub 1). Sądząc po nazwie kolumny (activ) 0 oznacza element nieaktywny, a 1 aktywny. Rekordów z 1 pewnie będzie zdecydowanie więcej niż tych z 0 i to one będę wyszukiwane. Zakładając więc indeks na taką kolumnę nie zyskamy nic poza narzutami związanymi z posiadaniem indeksu (miejsce, wolniejsza aktualizacja). Dawniej również dawałem indeksy na tego typu pola, ale po przeczytaniu książki SQL Server 2005. Programowanie. Od podstaw zmieniłem swoje podejście.

Ok, ale książka jest do MSSQL, a temat o MySQL. Więc nie można generalizować, najpewniej porobić benchmark. Ale wciąż jestem zdania, że nie zaszkodzi ten jeden indeks więcej.

z indexem na activ zapytanie:
select * from table where activ=1
weźmie pod analize tylko rekordy z activ=1
bez indexu to samo zapytanie weźmie do analizy wszystkie rekordy. Przy milionie rekordów naprawdę odczujecie roznice

INT zajmuje kilka bajtów, TINYINT zajmuje jeden bajt. Przemnóż sobie teraz to przez kilka milionow i juz bedziesz wiedzial na czym zyskasz pisząc optymalnie.

Dzięki. Chciałbym jednak poruszyć jeszcze kwestię ilości indeksów. Przykładowo posiadam tabelę dla ofert, gdzie blisko 20-30 pól (tinyint(1) o wartości 1 lub 0) to warunki odpowiadające kryteriom w wyszukiwarce (np. czy oferta zawiera opcję 1, opcję 2 ... opcję 20 itp. ). Chciałbym dla takich pól nałożyć indeksy, jednak czy nie będzie ich za dużo?

podaj przykladowe opcje. Byc moze przekombinowales i niepotrzebnie zrobiles z nich oddzielne pola tinyint. Zapewne by wystarczyło jedno pole

dla ofert turystycznych mam przykładowo takie opcje (czy oferta zawiera): wyżywienie, telewizja, boisko, kuchnia, lazienka - takich pól w tabeli "oferty" mam do 30 - wszystkie tinyint(1) i zawierają jedynie wartości 1 lub 0 (jest lub nie ma). Pola te będą służyć do wyświetlenia szczegółów oferty, ale również do zaawansowanej wyszukiwarki ofert na stronie.

No ale przecież trzeba wziąć pod uwagę jaki będzie rozkład wartości 0 / 1. Najprawdopodobniej zdecydowana większość rekordów będzie miała wartość 1. Rekordy z activ=0 to będą (zapewne) nowe rekordy czekające na akceptację. Po akceptacji status zmieni się na 1, a w przypadku braku akceptacji rekord zostanie pewnie usunięty (bo po co go trzymać?). W takim przypadku z miliona rekordów robi się (strzelam) 9 990 000 rekordów ze statusem 1 i 10 000 ze statusem 0. Czy w takim przypadku "naprawdę odczujemy różnicę"? Wątpię. Jeżeli natomiast niezaakceptowane rekordy nie byłyby usuwane to może lepiej byłoby je przenieść do osobnej tabeli jako historia niezaakceptowanych wpisów.

no, i tak jak myslalem, mozna to wszystko zapisac w jednym polu stosujac operacje bitowe.
dla typu tinyint zmiescisz 8 opcji. Jak bedziesz chciał wiecej opcji, uzyj wiekszego typu.

zasada dzialania:
stosowac bedziemy operacje bitowe - znasz sie co nie co na bitach?

1 bajt = 8 bitow = 00000000 - kazdy bit moze byc wykorzystany do zapisu opcji
liczba 1 - opcja 1 1000
liczba 2 - opcja 2 0100
liczba 4 - opcja 3 0010
liczba 8 - opcja 4 0001
....

liczba 3 - opcja 1 i 2 1100
liczba 14 - opcja 2,4,8 0111

mniej wiecej lapiesz?

jak chcesz zapisac do pola opcje 1,2,3 to robisz w php

[PHP] pobierz, plaintext 
$zm = 1 | 2 | 4;
[PHP] pobierz, plaintext 

i tą wartosc wkladasz do pola

A jak w baze chcesz wyszukac pol z opcją np. 4 to musisz uzyc logicznego AND

[SQL] pobierz, plaintext 
SELECT * FROM TABLE WHERE pole & 8
[SQL] pobierz, plaintext 

Analogicznie reszta. Proste, nieprawdaz?


a zes sie uczepil tego active... post wyzej wyraźnie pokazuje ze są to opcje turystyczne i tam juz nie ma ze wszystkie są 1

Uczepiłem się bo tego tyczył problem nie przekonałeś mnie, że stosowanie indeksu na tego typu polu ma sens.

Swoją drogą: czy przypadkiem liczby w systemie dwójkowym nie zapisujemy "od tyłu"?

Chyba raczej:

Nie wiem, może w MySQL działa to odwrotnie hehe

to sobie przeprowadź test ktory przedstawilem pare postow wczesniej

zależy jak leży. W różnych publikacjach różnie piszą w zależności od kontekstu. Tutaj zaś chodziło mi o wizualizacje a nie o wierne przedstawienie zapisu