Du kan ikke oprette et indeks på en visning:http:/ /dev.mysql.com/doc/refman/5.7/en/view-restrictions.html , så man må håbe indekset bliver brugt. https://stackoverflow.com/a/7922711/3595565
Løsning
Der er en løsning nævnt i kommentarerne til en anden del af dokumentationen:https://dev.mysql.com/doc/refman/5.5/en/create-view.html I hvilken du opretter en almindelig tabel og indstiller dit specialiserede indeks og indlæser dataene fra visningen i tabellen.
LOCK TABLES materializedView WRITE;
TRUNCATE materializedView;
INSERT INTO materializedView SELECT * FROM regularView;
UNLOCK TABLES;
Hvorfor gør din forespørgsel ikke brug af indekserne?
Når du bruger UNION
i en SELECT
mysql opretter en midlertidig tabel for at gemme dataene. Da en visning er en 'genvej' til din mere komplekse forespørgsel, når du kalder select vil den igen udføre foreningen, brug en midlertidig tabel... brug den fristende algoritme til at behandle dataene.
Tjek manualen igen:http://dev.mysql. com/doc/refman/5.7/da/view-restrictions.html
Konklusion :UNION
i din forespørgsel forhindrer visningen i at bruge indekserne.
Kilder
spørgsmål i mysql-forum til det samme problem svar:
fejlrapport "OPRET IKKE MIDLERTIDIGE TABELLER FOR UNION ALLE"
Rettet i MySQL 5.7 http:/ /dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-3.html
Nogle testdata for at tjekke profileren
CREATE TABLE test1 (
id int auto_increment PRIMARY KEY,
col1 varchar(50),
col2 varchar(50)
);
CREATE TABLE test2 (
id int auto_increment PRIMARY KEY,
col1 varchar(50),
col2 varchar(50)
);
INSERT INTO test1 (col1, col2)
VALUES
('test', 'testcol2'),
('test', 'testcol2'),
('test', 'testcol2'),
('test', 'testcol2'),
('test', 'testcol2'),
('test', 'testcol2');
INSERT INTO test2 (col1, col2)
VALUES
('test2', 'testcol2'),
('test2', 'testcol2'),
('test2', 'testcol2'),
('test2', 'testcol2'),
('test2', 'testcol2'),
('test2', 'testcol2');
CREATE VIEW testview AS
SELECT * FROM test1
UNION
SELECT * FROM test2;
Tjek profileren:
SET PROFILING = 1;
SELECT * FROM testview WHERE id = 1;
+----+-------+----------+
| id | col1 | col2 |
+----+-------+----------+
| 1 | test | testcol2 |
| 1 | test2 | testcol2 |
+----+-------+----------+
SHOW PROFILE;
+--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000017 |
| Waiting for query cache lock | 0.000004 |
| checking query cache for query | 0.000029 |
| checking permissions | 0.000006 |
| Opening tables | 0.000121 |
| System lock | 0.000012 |
| checking permissions | 0.000014 |
| checking permissions | 0.000032 |
| optimizing | 0.000004 |
| statistics | 0.000007 |
| preparing | 0.000006 |
| executing | 0.000003 |
| Sending data | 0.000046 |
| optimizing | 0.000003 |
| statistics | 0.000004 |
| preparing | 0.000003 |
| executing | 0.000002 |
| Sending data | 0.000023 |
| optimizing | 0.000003 |
| statistics | 0.000003 |
| preparing | 0.000003 |
| executing | 0.000002 |
| Sending data | 0.000008 |
| removing tmp table | 0.000005 |
| Sending data | 0.000005 |
| Waiting for query cache lock | 0.000002 |
| Sending data | 0.000024 |
| init | 0.000011 |
| optimizing | 0.000006 |
| statistics | 0.000004 |
| preparing | 0.000006 |
| executing | 0.000002 |
| Sending data | 0.000021 |
| end | 0.000003 |
| query end | 0.000004 |
| closing tables | 0.000002 |
| removing tmp table | 0.000004 |
| closing tables | 0.000006 |
| freeing items | 0.000005 |
| Waiting for query cache lock | 0.000003 |
| freeing items | 0.000013 |
| Waiting for query cache lock | 0.000002 |
| freeing items | 0.000002 |
| storing result in query cache | 0.000003 |
| logging slow query | 0.000002 |
| cleaning up | 0.000003 |
+--------------------------------+----------+
Jeg kan ikke tage for meget information ud af profilen, men den nævner midlertidig tabel, nok (for mig) til at validere min konklusion.