Index-Optimierung für die Suche auf Zeitstempel

SELECT 
node_session_seq, 
call_start, 
YEAR(call_start) AS year, 
quarter(call_start) as qtr, 
ADDDATE(LAST_DAY(SUBDATE(call_start, INTERVAL 1 MONTH)),1) AS month, 
CAST(call_start AS DATE) AS date, 
CASE WHEN MAX(queue_time) <= sla AND MAX(cont_disp) = 1 THEN 0 ELSE 1 END AS presented, 
CASE WHEN MAX(cont_disp) = 2 THEN 1 ELSE 0 END AS handled, 
CASE WHEN MAX(queue_time) <= sla AND MAX(cont_disp = 2) THEN 1 ELSE 0 END AS met_sla, 
CASE WHEN MAX(queue_time) > sla AND MAX(cont_disp = 1) THEN 1 ELSE 0 END AS abandoned 
FROM 
emsupport.t_cisco_csq_ad csq_ad where call_start > '2013-03-30 00:00:00' 
GROUP BY node_session_seq

Oben ist eine Abfrage, die ich bin mit einem Datamart für Anrufberichte zu bauen. Meine Frage umgibt Leistung - Strom gibt es 5 Indizes für die Tabelle:Index-Optimierung für die Suche auf Zeitstempel

Primärschlüssel/INT (11) Auto-Inkrement
call_start/DATETIME-
cont_disp/VARCHAR (45) - gültige Werte sind 1 , 2,3,4,99
csq_name/VARCHAR (90)/UNRELATED
app_name/VARCHAR (90)/UNRELATED

Soll ich nur Indizes hinzufügen, eine queue_time d SLA? SLA wäre entweder 45, 60, 90, 120, 200 oder 300 im Zeitstempelformat, genau wie die Warteschlangenzeit. Warteschlangenzeit wird einige Gemeinsamkeiten haben; Ein Großteil unseres Anrufvolumens wird in < 60 Sekunden beantwortet. Momentan sehe ich eine Leistung von etwa 1000 Reihen in 23-25 Sekunden. Das ist mit einem Teildatensatz von etwa 515.000 Zeilen, mit insgesamt etwa 750k.

Werden Indizes den Trick machen? Oder sollte ich noch etwas anderes machen? Ich bin kein DBA, nur ein Typ, der genug SQL kennt, um mehr Arbeit auf seinem Teller zu haben.

Danke für die Hilfe - oh und PS - Einfügeleistung ist kein Problem. Die täglichen Stunden werden von einem Skript erledigt, das nur neue Daten einfügt.

Jim

// Redaktion/Create Statement für Tabelle Hinzufügen

CREATE TABLE `t_cisco_csq_ad` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `node_session_seq` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `call_start` datetime DEFAULT NULL, 
    `call_end` datetime DEFAULT NULL, 
    `cont_disp` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `origin_dn` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `dest_dn` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `called_number` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `app_name` varchar(90) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `csq_name` varchar(90) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `queue_time` time DEFAULT NULL, 
    `agent_name` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `ring_time` time DEFAULT NULL, 
    `talk_time` time DEFAULT NULL, 
    `work_time` time DEFAULT NULL, 
    `isrna` tinyint(1) DEFAULT '0', 
    `agent_resourceid` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `sla` time DEFAULT NULL, 
    PRIMARY KEY (`id`), 
    KEY `i_call_start` (`call_start`), 
    KEY `i_csq_name` (`csq_name`), 
    KEY `i_app_name` (`app_name`), 
    KEY `i_cont_disp` (`cont_disp`) 
ENGINE=InnoDB AUTO_INCREMENT=676886 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Quelle

2016-05-09 jconnors

Bitte geben Sie 'SHOW CREATE TABLE', Ihre Beschreibung von' SLA' und Warteschlange Zeit ist ungenau. –

@ rick-james das SLA ist einfach die vertraglich vereinbarte Servicezeit für unsere Kunden. Im Grunde genommen ist die queue_time die Zeit, die man braucht, um jeden Anruf zu beantworten, die sla ist die Zeit, in der sie verglichen wird. Wäre es sinnvoller, den Vergleich in einem Trigger durchzuführen, wenn neue Zeilen eingefügt werden, den Vergleich durchzuführen und ihn einfach als eine Spalte als wahr/falsch zu speichern? Würden das schnellere Zusammenfassungsergebnisse liefern? – jconnors

Der einzige nützliche Index ist INDEX(call_start).

Es riecht nach cont_disp sollte TINYINT UNSIGNED sein. Oder vielleicht ENUM(...)

Quelle

2016-05-09 23:39:24

Index-Optimierung für die Suche auf Zeitstempel

Antwort

Verwandte Themen