Hopefully a very quick question: I'm having some trouble getting the following
index creation statement to work. I'm using MySQL Workbench.
CREATE INDEX HIRE_DATE_INDEX
ON Employee (hiredate)
WHERE hiredate > '2001-01-01';
I'm trying to get the following index creation to work, however regardless of what I look up online the following is listed as the proper syntax but for some reason that is unfathomable at this point, the index is specifically saying that the where clause is in the incorrect place.
I'm clearly missing something in the examples.
(Context, just trying to create a filtered index only interested in dates greater then).
It looks like this should be easy as hell, what am I missing here?
You don't need the WHERE clause. But MySQL doesn't support filtered index. (Reference here)
CREATE INDEX HIRE_DATE_INDEX
ON Employee (hiredate);
Also that command doesn't work if you try to create a primary key. If that's the case, you need to use ALTER TABLE command.
I'm using php and MySQL with a rather large MySQL database and I am trying to use idexes for the first time. I get the concept that the server will look through the index first but I'm moving trouble getting the server to use the index. So my questions are:
Does having a primary key (thus primary index?) in the table get used over the index I'm trying to use from another column? Do I have to explicitly specify the index in the select query? (I'm using several table joins, btw)
Does anyone know of a good beginners guide to using MySQL indexes? I haven't found a good one!
An important rule for mysql indexes, say you have the following index:
KEY(A,B,C)
Then in your code you have a where clause or join such as:
WHERE B = 'mydata' AND C = 'moredata'
Mysql will not be able to make use of the index for the query because the indexes work in the order given and the column A has not been included.
The fix is to either use A in the query or re-order the index (or add a second index) as so:
KEY(C,B,A)
or (if you don`t need A at all in the WHERE/JOIN):
KEY(C,B)
Also check out explain which should help you find why your indexes are not being used.
Method 1:
SELECT * FROM `wordpressusers` WHERE user_login='user10000001'
Result from PhpMyadmin:
Method2:
SELECT user_login FROM `wordpressusers` WHERE user_login='user10000001'
Result from PhpMyadmin:
What I think is method 2 is faster because it is selecting user_login column directly and MYSQL doesn't look to another columns. Correct me If i'm wrong.
I tried to query this in phpmyadmin and looking at the result, they are the same. I think this would make difference if the database is very big..
Actually, I expect #2 to be faster due to the reason already given.
This question is to settle an argument between me and a coworker.
Let's say we have the following query, executed on a standard LAMP server.
SELECT field1, field2, field3
FROM some_table
WHERE some_table.field1 = 123
ORDER BY field2 DESC
LIMIT 0, 15
Now let's assume the limit clause is vulnerable to SQL injection.
LIMIT [insert anything here], [also insert anything here]
The point of my coworker is that there is no way to exploit this injection, so there's no need to escape it (since it take more processing power and stuff).
I think her reasoning is stupid, but I can't figure out how to prove her wrong by finding an example.
I can't use UNION since the query is using an ORDER BY clause, and the MySQL user running the query doesn't have the FILE priviledge so using INTO OUTFILE is also out of the question.
So, can anyone tell us who is right on this case?
Edit: the query is executed using PHP, so adding a second query using a semicolon won't work.
The LIMIT clause is vulnerable to SQL injection, even when it follows an ORDER BY, as Maurycy Prodeus demonstrated earlier this year:
mysql> SELECT field FROM user WHERE id >0 ORDER BY id LIMIT 1,1
procedure analyse(extractvalue(rand(),concat(0x3a,version())),1);
ERROR 1105 (HY000): XPATH syntax error: ':5.5.41-0ubuntu0.14.04.1'
Voilà! The above solution is based on handy known technique of so-called error based injection. If, therefore, our vulnerable web application discloses the errors of the database engine (this is a real chance, such bad practices are common), we solve the problem. What if our target doesn’t display errors? Are we still able to exploit it successfully?
It turns out that we can combine the above method with another well-known technique – time based injection. In this case, our solution will be as follows:
SELECT field FROM table WHERE id > 0 ORDER BY id LIMIT 1,1
PROCEDURE analyse((select extractvalue(rand(),
concat(0x3a,(IF(MID(version(),1,1) LIKE 5, BENCHMARK(5000000,SHA1(1)),1))))),1)
It works. What is interesting that using SLEEP is not possible in this case. That’s why there must be a BENCHMARK instead.
I would insert this:
1; DELETE FROM some_table WHERE 1; --
Just after the limit, that will select 1 row from some_table, then DELETE all some_table rows. then the rest will be considered as a comment.
SQL Injection occurs if “externally-influenced input […] could modify the intended SQL command”. And in this case it’s clear that user input can modify the intended SQL command.
However, exploitability is another question. You may not be able to exploit it today. But maybe someday someone is able to exploit it because:
The database connection layer has changed and it is possible to execute multiple statements at once.
The statement has changed and it is possible to use UNION.
The user privileges have changed and it is possible to use INTO OUTFILE/INTO DUMPFILE.
Someone finds a way that you may not have thought of. Have you noticed you can store the result in variables and/or execute a stored procedure?
If you are creating the SQL query from user input, then it will be vulnerable, unless you are using strong typing way before you get anywhere near generating the query. In such a case, there's no way you could make an integer become text saying to drop a table, for example.
Never trust user input, and always perform bounds checking. For example, don't even bother doing the query if the limit values are negative.
You should come with a coding example, not a query example as you do now. She is right on the fact that you cannot really alter a statement since the order by function is always "last". So yes, when you are manually inputting those query's on a sql server, you simply cannot alter the query to output something different rather than a error message. Yet, when you simply add an other query.. you can :)
Finish the last user input as a true value to let the first query run successfully, and add a ';'. Now you can start your own query.
I just have done this on my local mysql server:
SELECT * FROM city order by ID desc limit 0,15; SELECT * FROM city
Even so, in a strong case where there is absolute 0% chance someone could alter the statement, you simply do not even want to receive possible altered data. There should be a reason you use the LIMIT dynamically. Once a person can change your reason, you already have failed. Its not even about risking damage, losing data or what ever. You do not want any manipulation in any way.
I have a MySQL query (running MySQL 5.0.88), which I'm trying to speed up. The underlying table has multiple indices and for the query in question, the wrong index is used (i_active - 16.000 rows, vs. i_iln - 7 rows).
I'm not very experienced with MySQL but read there is a use index hint, which can force mySQL to use a certain index. I'm trying it like this:
SELECT art.firma USE INDEX (i_iln)
...
but this produces a MySQL error.
Question:
Can anyone tell me what I'm doing wrong? (Except running 5.0.88, which I can't change.)
You missed the
FROM table
Correct SQL should be:
SELECT art.firma FROM your_table USE INDEX (i_iln) WHERE ....
select * from table use index (idx);
http://dev.mysql.com/doc/refman/5.0/en/index-hints.html
sometimes, with use index (index_name) optimizer might go for table scan, if you use hint force index, optimizer will be forced to use index, will go for table scan only if no ways left to get the rows with provided index.
SELECT art.firma FROM art FORCE INDEX (i_iln);
for more detail on hints USE INDEX and FORCE INDEX check this link
Select Coloumn1,Coloumn2,Coloumn.... FROM TABLE_NAME USE INDEX(index_name)
WHERE Coloumn="condition";
if you have correct index thn you dnt need to use index(). your query automic select correct index.If your query slow after using index thn recheck your index ,something wrong in index.
thanks in advance.enter code here