Optimierung bei Datumsvergleich möglich?

Hallo,
vielleicht hat einer eine Idee, wie man folgende Abfrage noch optimieren
könnte, da sie etwa 1 Minute und 20 Sekunden dauert. Ich habe zwei
Tabellen, die über eine Rufnummer miteinander verbunden werden. Die eine
Tabelle, die Informationen über ausgehende Kurznachrichten (SMS)
beinhaltet, hat etwa 5800 Datensätze, die zweite Tabelle, die
Informationen über Anrufer bereithält, etwa 2600000 Datensätze.

Ich möchte Anrufer ermitteln, die nach dem Versand einer SMS sich
telefonisch gemeldet haben.

Tabelle sms_out (gesendete SMS)
+-------------+-----------------------+
| Field | Type |
+-------------+-----------------------+
| caller_id | varchar(32) |
| sms_pool_id | mediumint(7) unsigned |
| sms_date | datetime |
| sms_out_inc | int(11) |
+-------------+-----------------------+

Tabelle calls_in_smsaction (Infos zum Anrufer)
+--------------+----------------------+
| Field | Type |
+--------------+----------------------+
| date_time | datetime |
| caller_id | varchar(32) |
| serv_id | varchar(12) |
| sms_sent | smallint(5) unsigned |
| calls_in_inc | int(11) |
+--------------+----------------------+

Wichtig sind hier für die Abfrage nur caller_id zur Verknüpfung, das
Datum, wann die SMS versendet wurde (Tabelle a), und das Datum des
Rückrufs (Tabelle b).

Die Abfrage sieht zur Zeit so aus.

select a.caller_id
from sms_out as a, calls_in_smsaction as b
where a.caller_id=b.caller_id
and a.sms_date < b.date_time


Explain liefert folgende Informationen

*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: a
type: ALL
possible_keys: idx_caller_id
key: NULL
key_len: NULL
ref: NULL
rows: 5945
Extra:
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: b
type: ref
possible_keys: idx_caller_id
key: idx_caller_id
key_len: 9
ref: q1calls.a.caller_id
rows: 57
Extra: Using where
2 rows in set (0.00 sec)


Indizes habe ich bei beiden Tabellen für die Spalte caller_id angelegt

show index from calls_in_smsaction

*************************** 1. row ***************************
Table: calls_in_smsaction
Non_unique: 0
Key_name: PRIMARY
Seq_in_index: 1
Column_name: calls_in_inc
Collation: A
Cardinality: 2596993
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
*************************** 2. row ***************************
Table: calls_in_smsaction
Non_unique: 1
Key_name: idx_caller_id
Seq_in_index: 1
Column_name: caller_id
Collation: A
Cardinality: 45561
Sub_part: 6
Packed: NULL
Null: YES
Index_type: BTREE
Comment:




show index from sms_out
*************************** 1. row ***************************
Table: sms_out
Non_unique: 0
Key_name: PRIMARY
Seq_in_index: 1
Column_name: sms_out_inc
Collation: A
Cardinality: 5945
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
*************************** 2. row ***************************
Table: sms_out
Non_unique: 1
Key_name: idx_caller_id
Seq_in_index: 1
Column_name: caller_id
Collation: A
Cardinality: 990
Sub_part: 6
Packed: NULL
Null:
Index_type: BTREE
Comment:


Kann man in diesem Fall noch etwas optimieren?

Gruß,
Thomas B

Re: Optimierung bei Datumsvergleich möglich?

Thomas Barth schrieb:

> select a.caller_id
> from sms_out as a, calls_in_smsaction as b
> where a.caller_id=b.caller_id
> and a.sms_date < b.date_time
^^^^^^^^^^^^^^^^^^^^^^^^

> Indizes habe ich bei beiden Tabellen für die Spalte caller_id angelegt

Naja, und die Indizes über a.sms_date und b.date_time? Bin mir jetzt
nicht sicher, ob MySQL in hinreichend neuen Versionen bereits mehrere
Indizes pro Tabelle in einer Query verwenden kann oder ob man auf
kombinierte Indizes zurückgreifen muss.

gruss, heli

Re: Optimierung bei Datumsvergleich möglich?

On 09.03.2007 09:41, Thomas Barth wrote:
> Hallo,
> vielleicht hat einer eine Idee, wie man folgende Abfrage noch optimieren
> könnte, da sie etwa 1 Minute und 20 Sekunden dauert. Ich habe zwei
> Tabellen, die über eine Rufnummer miteinander verbunden werden. Die eine
> Tabelle, die Informationen über ausgehende Kurznachrichten (SMS)
> beinhaltet, hat etwa 5800 Datensätze, die zweite Tabelle, die
> Informationen über Anrufer bereithält, etwa 2600000 Datensätze.
>
> Ich möchte Anrufer ermitteln, die nach dem Versand einer SMS sich
> telefonisch gemeldet haben.
>
> Tabelle sms_out (gesendete SMS)
> +-------------+-----------------------+
> | Field | Type |
> +-------------+-----------------------+
> | caller_id | varchar(32) |
> | sms_pool_id | mediumint(7) unsigned |
> | sms_date | datetime |
> | sms_out_inc | int(11) |
> +-------------+-----------------------+
>
> Tabelle calls_in_smsaction (Infos zum Anrufer)
> +--------------+----------------------+
> | Field | Type |
> +--------------+----------------------+
> | date_time | datetime |
> | caller_id | varchar(32) |
> | serv_id | varchar(12) |
> | sms_sent | smallint(5) unsigned |
> | calls_in_inc | int(11) |
> +--------------+----------------------+
>
> Wichtig sind hier für die Abfrage nur caller_id zur Verknüpfung, das
> Datum, wann die SMS versendet wurde (Tabelle a), und das Datum des
> Rückrufs (Tabelle b).
>
> Die Abfrage sieht zur Zeit so aus.
>
> select a.caller_id
> from sms_out as a, calls_in_smsaction as b
> where a.caller_id=b.caller_id
> and a.sms_date < b.date_time
>
>
> Explain liefert folgende Informationen
>
> *************************** 1. row ***************************
> id: 1
> select_type: SIMPLE
> table: a
> type: ALL
> possible_keys: idx_caller_id
> key: NULL
> key_len: NULL
> ref: NULL
> rows: 5945
> Extra:
> *************************** 2. row ***************************
> id: 1
> select_type: SIMPLE
> table: b
> type: ref
> possible_keys: idx_caller_id
> key: idx_caller_id
> key_len: 9
> ref: q1calls.a.caller_id
> rows: 57
> Extra: Using where
> 2 rows in set (0.00 sec)
>
>
> Indizes habe ich bei beiden Tabellen für die Spalte caller_id angelegt
>
> show index from calls_in_smsaction
>
> *************************** 1. row ***************************
> Table: calls_in_smsaction
> Non_unique: 0
> Key_name: PRIMARY
> Seq_in_index: 1
> Column_name: calls_in_inc
> Collation: A
> Cardinality: 2596993
> Sub_part: NULL
> Packed: NULL
> Null:
> Index_type: BTREE
> Comment:
> *************************** 2. row ***************************
> Table: calls_in_smsaction
> Non_unique: 1
> Key_name: idx_caller_id
> Seq_in_index: 1
> Column_name: caller_id
> Collation: A
> Cardinality: 45561
> Sub_part: 6
> Packed: NULL
> Null: YES
> Index_type: BTREE
> Comment:
>
>
>
>
> show index from sms_out
> *************************** 1. row ***************************
> Table: sms_out
> Non_unique: 0
> Key_name: PRIMARY
> Seq_in_index: 1
> Column_name: sms_out_inc
> Collation: A
> Cardinality: 5945
> Sub_part: NULL
> Packed: NULL
> Null:
> Index_type: BTREE
> Comment:
> *************************** 2. row ***************************
> Table: sms_out
> Non_unique: 1
> Key_name: idx_caller_id
> Seq_in_index: 1
> Column_name: caller_id
> Collation: A
> Cardinality: 990
> Sub_part: 6
> Packed: NULL
> Null:
> Index_type: BTREE
> Comment:
>
>
> Kann man in diesem Fall noch etwas optimieren?
>
> Gruß,
> Thomas B

Versuch's doch mal mit einem zusammengesetzten Index auf (caller_id,
sms_date) und (caller_id, date_time).

robert

Re: Optimierung bei Datumsvergleich möglich?

Robert Klemme wrote:
> On 09.03.2007 09:41, Thomas Barth wrote:
>> Hallo,
>> vielleicht hat einer eine Idee, wie man folgende Abfrage noch optimieren
>> könnte, da sie etwa 1 Minute und 20 Sekunden dauert. Ich habe zwei
>> Tabellen, die über eine Rufnummer miteinander verbunden werden. Die eine
>> Tabelle, die Informationen über ausgehende Kurznachrichten (SMS)
>> beinhaltet, hat etwa 5800 Datensätze, die zweite Tabelle, die
>> Informationen über Anrufer bereithält, etwa 2600000 Datensätze.
>>
>> Ich möchte Anrufer ermitteln, die nach dem Versand einer SMS sich
>> telefonisch gemeldet haben.
>>
>> Tabelle sms_out (gesendete SMS)
>> +-------------+-----------------------+
>> | Field | Type |
>> +-------------+-----------------------+
>> | caller_id | varchar(32) |
>> | sms_pool_id | mediumint(7) unsigned |
>> | sms_date | datetime |
>> | sms_out_inc | int(11) |
>> +-------------+-----------------------+
>>
>> Tabelle calls_in_smsaction (Infos zum Anrufer)
>> +--------------+----------------------+
>> | Field | Type |
>> +--------------+----------------------+
>> | date_time | datetime |
>> | caller_id | varchar(32) |
>> | serv_id | varchar(12) |
>> | sms_sent | smallint(5) unsigned |
>> | calls_in_inc | int(11) |
>> +--------------+----------------------+
>>
>> Wichtig sind hier für die Abfrage nur caller_id zur Verknüpfung, das
>> Datum, wann die SMS versendet wurde (Tabelle a), und das Datum des
>> Rückrufs (Tabelle b).
>>
>> Die Abfrage sieht zur Zeit so aus.
>>
>> select a.caller_id
>> from sms_out as a, calls_in_smsaction as b
>> where a.caller_id=b.caller_id
>> and a.sms_date < b.date_time
>>
>>
>> Explain liefert folgende Informationen
>>
>> *************************** 1. row ***************************
>> id: 1
>> select_type: SIMPLE
>> table: a
>> type: ALL
>> possible_keys: idx_caller_id
>> key: NULL
>> key_len: NULL
>> ref: NULL
>> rows: 5945
>> Extra:
>> *************************** 2. row ***************************
>> id: 1
>> select_type: SIMPLE
>> table: b
>> type: ref
>> possible_keys: idx_caller_id
>> key: idx_caller_id
>> key_len: 9
>> ref: q1calls.a.caller_id
>> rows: 57
>> Extra: Using where
>> 2 rows in set (0.00 sec)
>>
>>
>> Indizes habe ich bei beiden Tabellen für die Spalte caller_id angelegt
>>
>> show index from calls_in_smsaction
>>
>> *************************** 1. row ***************************
>> Table: calls_in_smsaction
>> Non_unique: 0
>> Key_name: PRIMARY
>> Seq_in_index: 1
>> Column_name: calls_in_inc
>> Collation: A
>> Cardinality: 2596993
>> Sub_part: NULL
>> Packed: NULL
>> Null:
>> Index_type: BTREE
>> Comment:
>> *************************** 2. row ***************************
>> Table: calls_in_smsaction
>> Non_unique: 1
>> Key_name: idx_caller_id
>> Seq_in_index: 1
>> Column_name: caller_id
>> Collation: A
>> Cardinality: 45561
>> Sub_part: 6
>> Packed: NULL
>> Null: YES
>> Index_type: BTREE
>> Comment:
>>
>>
>>
>>
>> show index from sms_out
>> *************************** 1. row ***************************
>> Table: sms_out
>> Non_unique: 0
>> Key_name: PRIMARY
>> Seq_in_index: 1
>> Column_name: sms_out_inc
>> Collation: A
>> Cardinality: 5945
>> Sub_part: NULL
>> Packed: NULL
>> Null:
>> Index_type: BTREE
>> Comment:
>> *************************** 2. row ***************************
>> Table: sms_out
>> Non_unique: 1
>> Key_name: idx_caller_id
>> Seq_in_index: 1
>> Column_name: caller_id
>> Collation: A
>> Cardinality: 990
>> Sub_part: 6
>> Packed: NULL
>> Null:
>> Index_type: BTREE
>> Comment:
>>
>>
>> Kann man in diesem Fall noch etwas optimieren?
>>
>> Gruß,
>> Thomas B
>
> Versuch's doch mal mit einem zusammengesetzten Index auf (caller_id,
> sms_date) und (caller_id, date_time).
>
> robert

Brachte leider überhaupt nichts. Ein mehrspaltiger Index auf caller_id
und date_time scheint in diesem Fall MySQL nicht zu interessieren.

Indizes hatte ich bei beiden Tabellen gelöscht und neu angelegt mit

create index idx_call_date on sms_out (caller_id(6), sms_date);

Explain liefert sogar die gleichen Information wie bereits in meiner
Nachricht geschrieben.

Gruß,
Thomas B

Re: Optimierung bei Datumsvergleich möglich?

On 09.03.2007 10:44, Thomas Barth wrote:
> Robert Klemme wrote:
>> On 09.03.2007 09:41, Thomas Barth wrote:
>>> Hallo,
>>> vielleicht hat einer eine Idee, wie man folgende Abfrage noch
>>> optimieren könnte, da sie etwa 1 Minute und 20 Sekunden dauert. Ich
>>> habe zwei Tabellen, die über eine Rufnummer miteinander verbunden
>>> werden. Die eine Tabelle, die Informationen über ausgehende
>>> Kurznachrichten (SMS) beinhaltet, hat etwa 5800 Datensätze, die
>>> zweite Tabelle, die Informationen über Anrufer bereithält, etwa
>>> 2600000 Datensätze.
>>>
>>> Ich möchte Anrufer ermitteln, die nach dem Versand einer SMS sich
>>> telefonisch gemeldet haben.
>>>
>>> Tabelle sms_out (gesendete SMS)
>>> +-------------+-----------------------+
>>> | Field | Type |
>>> +-------------+-----------------------+
>>> | caller_id | varchar(32) |
>>> | sms_pool_id | mediumint(7) unsigned |
>>> | sms_date | datetime |
>>> | sms_out_inc | int(11) |
>>> +-------------+-----------------------+
>>>
>>> Tabelle calls_in_smsaction (Infos zum Anrufer)
>>> +--------------+----------------------+
>>> | Field | Type |
>>> +--------------+----------------------+
>>> | date_time | datetime |
>>> | caller_id | varchar(32) |
>>> | serv_id | varchar(12) |
>>> | sms_sent | smallint(5) unsigned |
>>> | calls_in_inc | int(11) |
>>> +--------------+----------------------+
>>>
>>> Wichtig sind hier für die Abfrage nur caller_id zur Verknüpfung, das
>>> Datum, wann die SMS versendet wurde (Tabelle a), und das Datum des
>>> Rückrufs (Tabelle b).
>>>
>>> Die Abfrage sieht zur Zeit so aus.
>>>
>>> select a.caller_id
>>> from sms_out as a, calls_in_smsaction as b
>>> where a.caller_id=b.caller_id
>>> and a.sms_date < b.date_time
>>>
>>>
>>> Explain liefert folgende Informationen
>>>
>>> *************************** 1. row ***************************
>>> id: 1
>>> select_type: SIMPLE
>>> table: a
>>> type: ALL
>>> possible_keys: idx_caller_id
>>> key: NULL
>>> key_len: NULL
>>> ref: NULL
>>> rows: 5945
>>> Extra:
>>> *************************** 2. row ***************************
>>> id: 1
>>> select_type: SIMPLE
>>> table: b
>>> type: ref
>>> possible_keys: idx_caller_id
>>> key: idx_caller_id
>>> key_len: 9
>>> ref: q1calls.a.caller_id
>>> rows: 57
>>> Extra: Using where
>>> 2 rows in set (0.00 sec)
>>>
>>>
>>> Indizes habe ich bei beiden Tabellen für die Spalte caller_id angelegt
>>>
>>> show index from calls_in_smsaction
>>>
>>> *************************** 1. row ***************************
>>> Table: calls_in_smsaction
>>> Non_unique: 0
>>> Key_name: PRIMARY
>>> Seq_in_index: 1
>>> Column_name: calls_in_inc
>>> Collation: A
>>> Cardinality: 2596993
>>> Sub_part: NULL
>>> Packed: NULL
>>> Null:
>>> Index_type: BTREE
>>> Comment:
>>> *************************** 2. row ***************************
>>> Table: calls_in_smsaction
>>> Non_unique: 1
>>> Key_name: idx_caller_id
>>> Seq_in_index: 1
>>> Column_name: caller_id
>>> Collation: A
>>> Cardinality: 45561
>>> Sub_part: 6
>>> Packed: NULL
>>> Null: YES
>>> Index_type: BTREE
>>> Comment:
>>>
>>>
>>>
>>>
>>> show index from sms_out
>>> *************************** 1. row ***************************
>>> Table: sms_out
>>> Non_unique: 0
>>> Key_name: PRIMARY
>>> Seq_in_index: 1
>>> Column_name: sms_out_inc
>>> Collation: A
>>> Cardinality: 5945
>>> Sub_part: NULL
>>> Packed: NULL
>>> Null:
>>> Index_type: BTREE
>>> Comment:
>>> *************************** 2. row ***************************
>>> Table: sms_out
>>> Non_unique: 1
>>> Key_name: idx_caller_id
>>> Seq_in_index: 1
>>> Column_name: caller_id
>>> Collation: A
>>> Cardinality: 990
>>> Sub_part: 6
>>> Packed: NULL
>>> Null:
>>> Index_type: BTREE
>>> Comment:
>>>
>>>
>>> Kann man in diesem Fall noch etwas optimieren?
>>>
>>> Gruß,
>>> Thomas B
>>
>> Versuch's doch mal mit einem zusammengesetzten Index auf (caller_id,
>> sms_date) und (caller_id, date_time).
>>
>> robert
>
> Brachte leider überhaupt nichts. Ein mehrspaltiger Index auf caller_id
> und date_time scheint in diesem Fall MySQL nicht zu interessieren.
>
> Indizes hatte ich bei beiden Tabellen gelöscht und neu angelegt mit
>
> create index idx_call_date on sms_out (caller_id(6), sms_date);
>
> Explain liefert sogar die gleichen Information wie bereits in meiner
> Nachricht geschrieben.

Hast du die Statistiken aktualisiert? Sind die Tabellen überhaupt groß
genug, damit es für die DB interessant ist, Indexe zu verwenden?

http://dev.mysql.com/doc/refman/5.1/en/myisam-index-statisti cs.html

robert

Re: Optimierung bei Datumsvergleich möglich?

Thomas Barth wrote:
> Robert Klemme wrote:
>> On 09.03.2007 09:41, Thomas Barth wrote:
>>> Tabelle sms_out (gesendete SMS)
>>> +-------------+-----------------------+
>>> | Field | Type |
>>> +-------------+-----------------------+
>>> | caller_id | varchar(32) |
>>> | sms_pool_id | mediumint(7) unsigned |
>>> | sms_date | datetime |
>>> | sms_out_inc | int(11) |
>>> +-------------+-----------------------+
>>>
>>> Tabelle calls_in_smsaction (Infos zum Anrufer)
>>> +--------------+----------------------+
>>> | Field | Type |
>>> +--------------+----------------------+
>>> | date_time | datetime |
>>> | caller_id | varchar(32) |
>>> | serv_id | varchar(12) |
>>> | sms_sent | smallint(5) unsigned |
>>> | calls_in_inc | int(11) |
>>> +--------------+----------------------+
[snip]
>>>
>>> select a.caller_id
>>> from sms_out as a, calls_in_smsaction as b
>>> where a.caller_id=b.caller_id
>>> and a.sms_date < b.date_time
>>>
>>>
>>> Explain liefert folgende Informationen
>>>
>>> *************************** 1. row ***************************
>>> id: 1
>>> select_type: SIMPLE
>>> table: a
>>> type: ALL
>>> possible_keys: idx_caller_id
>>> key: NULL
^^^^
>>> key_len: NULL
>>> ref: NULL
>>> rows: 5945
>>> Extra:
>>> *************************** 2. row ***************************
>>> id: 1
>>> select_type: SIMPLE
>>> table: b
>>> type: ref
>>> possible_keys: idx_caller_id
>>> key: idx_caller_id
>>> key_len: 9
>>> ref: q1calls.a.caller_id
>>> rows: 57
>>> Extra: Using where
>>> 2 rows in set (0.00 sec)
[snip]
>> Versuch's doch mal mit einem zusammengesetzten Index auf (caller_id,
>> sms_date) und (caller_id, date_time).
>>
>> robert
>
> Brachte leider überhaupt nichts. Ein mehrspaltiger Index auf caller_id
> und date_time scheint in diesem Fall MySQL nicht zu interessieren.
>
> Indizes hatte ich bei beiden Tabellen gelöscht und neu angelegt mit
>
> create index idx_call_date on sms_out (caller_id(6), sms_date);
>
> Explain liefert sogar die gleichen Information wie bereits in meiner
> Nachricht geschrieben.

Auch in deinen ursprünglichen Abfragen benutzt MySQL nicht den Index
über caller_id. Die Begründung hatten wir gerade erst.

Schau mal hier: <12utv09afn0bk77@corp.supernews.com>

Lege den Index über die gesamte Spalte caller_id und es sollte gehen.

Andererseits habe ich bei `ID` immer direkt die Assoziation zu einem
numerischen Wert und nicht zu einem String. Wärst du mit einem
numerischen Index nicht besser bedient?

Grüße
Kai

Re: Optimierung bei Datumsvergleich möglich?

Thomas Barth schrieb:

> vielleicht hat einer eine Idee, wie man folgende Abfrage noch optimieren
> könnte, da sie etwa 1 Minute und 20 Sekunden dauert. [...]
>
> Wichtig sind [...]

Wichtig sind vor allem korrekt gesetzte Indizes. Dazu hast Du leider gar
nichts geschrieben. Vermutlich liegt da der Fehler.

Gruß. Claus
--
,~°O O
O ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /

Re: Optimierung bei Datumsvergleich möglich?

Robert Klemme schrieb:

> On 09.03.2007 10:44, Thomas Barth wrote:
>
>> [Fullquote gesnipt]

Nachdem ich die Originalnachricht dank Eurer unsinnigen Vollquoterei nun
bereits 4x in vollem Wortlaut auf meinem Rechner habe, möchte ich Euch
doch sehr bitten, einmal http://learn.to/quote durchzuarbeiten und zu
beherzigen, was dort steht.

Gruß. Claus
--
,~°O O
O ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /

Re: Optimierung bei Datumsvergleich möglich?

Claus Reibenstein wrote:
> Thomas Barth schrieb:
>
>> vielleicht hat einer eine Idee, wie man folgende Abfrage noch optimieren
>> könnte, da sie etwa 1 Minute und 20 Sekunden dauert. [...]
>>
>> Wichtig sind [...]
>
> Wichtig sind vor allem korrekt gesetzte Indizes. Dazu hast Du leider gar
> nichts geschrieben. Vermutlich liegt da der Fehler.
>
> Gruß. Claus

Also, du musst schon vollständig meine Nachricht lesen. Mit
show index from calls_in_smsaction/sms_out habe ich sehr wohl dazu etwas
geschrieben. Aber es hat sich sowieso erledigt, da ich nun einen
mehrspaltigen Index habe, mit dem die Abfrage viel schneller
abgearbeitet wird.

Gruß,
Thomas

Re: Optimierung bei Datumsvergleich möglich?

Kai Ruhnau wrote:

> Auch in deinen ursprünglichen Abfragen benutzt MySQL nicht den Index
> über caller_id. Die Begründung hatten wir gerade erst.
>

>
> Lege den Index über die gesamte Spalte caller_id und es sollte gehen.
>

Dann habe die Indexierung noch nicht richtig verstanden, wenn der Index
hier für die gesamte Spalte caller_id angelegt werden muss. Ich dachte,
es werden bei der Indexierung Gemeinsamkeiten zusammengefasst. Die finde
ich natürlich bei einer mobilen Rufnummer (caller_id) nur am Anfang
(Netzbetreiber und vielleicht noch ein paar weitere Ziffern). Jetzt muss
ich mich mit dem Kapitel Indexierung noch mal genauer befassen.

> Andererseits habe ich bei `ID` immer direkt die Assoziation zu einem
> numerischen Wert und nicht zu einem String. Wärst du mit einem
> numerischen Index nicht besser bedient?

Ja, du hast recht, es ist etwas irreführend. Aber bei mir im System ist
caller_id die Telefonnummer eines Anrufers. Führenden Nullen müssen
erhalten bleiben.

Gruß,
Thomas B

Re: Optimierung bei Datumsvergleich möglich?

Thomas Barth schrieb:

> Claus Reibenstein wrote:
>
>> Thomas Barth schrieb:
>>
>>> Wichtig sind [...]
>>
>> Wichtig sind vor allem korrekt gesetzte Indizes. Dazu hast Du leider gar
>> nichts geschrieben. Vermutlich liegt da der Fehler.
>
> Also, du musst schon vollständig meine Nachricht lesen. Mit
> show index from calls_in_smsaction/sms_out habe ich sehr wohl dazu etwas
> geschrieben.

Sorry, habe ich übersehen.

Gruß. Claus
--
,~°O O
O ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /

Re: Optimierung bei Datumsvergleich möglich?

Thomas Barth wrote:

>> Andererseits habe ich bei `ID` immer direkt die Assoziation zu einem
>> numerischen Wert und nicht zu einem String. Wärst du mit einem
>> numerischen Index nicht besser bedient?
>
> Ja, du hast recht, es ist etwas irreführend. Aber bei mir im System ist
> caller_id die Telefonnummer eines Anrufers. Führenden Nullen müssen
> erhalten bleiben.

Können ja. Was Du brauchst, ist eine weitere Tabelle, die eine rein interne
ID einer Telefonnummer zuordnet. Diese ist weiterhin varchar, die interne
ID ist eine Auto_Increment-ID.

BTW: Die führende Nullen in einer Telefonnummer fallen weg, wenn man mit der
internationalen Notation +49... arbeitet, die etwas mehr Information
beinhaltet, nämlich das Land, zu welchem die Nummer gehört.


Thomas
--
Ich kenne das auch, bin ja selbst Deutscher. Ich bin kleinkariert,
bürokratisch, humorlos, obrigkeitsgläubig... Ich würde die Liste gerne
fortführen, aber ich muß erstmal meinen Gartenzwerg geraderücken, der
hat sicheben zur Seite geneigt." (Sebastian Koppehel in dsnu)

Re: Optimierung bei Datumsvergleich möglich?

Kai Ruhnau wrote:

> Auch in deinen ursprünglichen Abfragen benutzt MySQL nicht den Index
> über caller_id. Die Begründung hatten wir gerade erst.
>
> Schau mal hier: <12utv09afn0bk77@corp.supernews.com>

Wesentlicher Unterschied: dort sollen *alle* Einträge sortiert werden; hier
jedoch soll auf Gleichheit von caller_id-Werten geprüft werden.

Beim Sortieren ist es klar, daß da ein Präfix-Index nicht vollständig
ausreicht und u. U. für (zu) viele Datensätze zusätzlich der komplette Wert
aus der Tabelle gelesen werden muß.

Hier jedoch geht es um Vergleiche im Zuge eines JOINs. Da kann der Index
schonmal für eine grobe Vorauswahl verwendet werden; für die (hoffentlich
nur wenigen) Fälle, wo er nicht eindeutig ist, werden dann die Werte aus
der Tabelle gelesen.

Aber ich sehe grade, daß der genannte Index eine Cardinality von 45561 hat,
bei (vermutlich) >= 2596993 Zeilen. Das wiederum könnte zu unscharf sein,
als daß der Index noch sinnvoll nutzbar wäre...


Thomas
--
Ich hätte gerne 5 neue Newsgruppen. Zwei davon wären ganz eilig, da
Geburtstagsgeschenke. Bitte um Benachrichtigung, damit ich nach
Einrichtung über den Namen befinden werde.
in de.alt.admin

Re: Optimierung bei Datumsvergleich möglich?

Thomas Barth wrote:

> Dann habe die Indexierung noch nicht richtig verstanden, wenn der Index
> hier für die gesamte Spalte caller_id angelegt werden muss. Ich dachte,
> es werden bei der Indexierung Gemeinsamkeiten zusammengefasst. Die finde
> ich natürlich bei einer mobilen Rufnummer (caller_id) nur am Anfang
> (Netzbetreiber und vielleicht noch ein paar weitere Ziffern). Jetzt muss
> ich mich mit dem Kapitel Indexierung noch mal genauer befassen.

Du solltest die Indizes mindestens so lange wählen, daß es möglichst wenige
Kollisionen gibt.

Bei Telefonnummern sind die paar Stellen für Vorwahl definitiv zu wenig; es
sollte möglicht viele eindeutige Werte im Index erfaßt sein. Anhaltspunkt
hierfür ist die Cardinality.

Wenn Du nach der Nummer '+49 170 1234567' suchst, im Index aber nur '+49
170' erfaßt ist, müssen alle diese Zeilen aus der Tabelle gelesen werden,
um dann die tatsächlichen Treffer auszufiltern.


> Ja, du hast recht, es ist etwas irreführend. Aber bei mir im System ist
> caller_id die Telefonnummer eines Anrufers. Führenden Nullen müssen
> erhalten bleiben.

Dazu hab ich ja vorhin schon was geschrieben.


Thomas
--
Jabber-ID: glglgl@amessage.info (keine Email-Adresse!)
Warum Jabber, was ist das und wie geht das?
http://de.wikibooks.org/wiki/Jabber-Kompendium:_Schnelleinst ieg