Does anyone know which one is faster:
SELECT * FROM table WHERE column LIKE '%text%';
or
SELECT * FROM table WHERE LOCATE('text',column)>0;
Added April 20th, 2015: Please read also Hallie's answer below
First one but marginally. Mostly because it doesn't have to do an extra > 0 comparison.
mysql> SELECT BENCHMARK(100000000,LOCATE('foo','foobar'));
+---------------------------------------------+
| BENCHMARK(100000000,LOCATE('foo','foobar')) |
+---------------------------------------------+
| 0 |
+---------------------------------------------+
1 row in set (3.24 sec)
mysql> SELECT BENCHMARK(100000000,LOCATE('foo','foobar') > 0);
+-------------------------------------------------+
| BENCHMARK(100000000,LOCATE('foo','foobar') > 0) |
+-------------------------------------------------+
| 0 |
+-------------------------------------------------+
1 row in set (4.63 sec)
mysql> SELECT BENCHMARK(100000000,'foobar' LIKE '%foo%');
+--------------------------------------------+
| BENCHMARK(100000000,'foobar' LIKE '%foo%') |
+--------------------------------------------+
| 0 |
+--------------------------------------------+
1 row in set (4.28 sec)
mysql> SELECT ##version;
+----------------------+
| ##version |
+----------------------+
| 5.1.36-community-log |
+----------------------+
1 row in set (0.01 sec)
+1 to #Mchl for answering the question most directly.
But we should keep in mind that neither of the solutions can use an index, so they're bound to do table-scans.
Trying to decide between a cloth or plastic adhesive bandage is kind of silly, when you're trying to patch the hull of the Titanic.
For this type of query, one needs a full-text search index. Depending on the size of the table, this will be hundreds or thousands of times faster.
I did some tests as Mchi did.And I think it's hard to say which one is faster. It looks like depending on the first occurrence of the substring.
mysql> select benchmark(100000000, 'afoobar' like '%foo%');
+----------------------------------------------+
| benchmark(100000000, 'afoobar' like '%foo%') |
+----------------------------------------------+
| 0 |
+----------------------------------------------+
1 row in set (9.80 sec)
mysql> select benchmark(100000000, locate('foo', 'afoobar'));
+------------------------------------------------+
| benchmark(100000000, locate('foo', 'afoobar')) |
+------------------------------------------------+
| 0 |
+------------------------------------------------+
1 row in set (8.08 sec)
mysql> select benchmark(100000000, 'abfoobar' like '%foo%');
+-----------------------------------------------+
| benchmark(100000000, 'abfoobar' like '%foo%') |
+-----------------------------------------------+
| 0 |
+-----------------------------------------------+
1 row in set (10.55 sec)
mysql> select benchmark(100000000, locate('foo', 'abfoobar'));
+-------------------------------------------------+
| benchmark(100000000, locate('foo', 'abfoobar')) |
+-------------------------------------------------+
| 0 |
+-------------------------------------------------+
1 row in set (10.63 sec)
mysql> select benchmark(100000000, 'abcfoobar' like '%foo%');
+------------------------------------------------+
| benchmark(100000000, 'abcfoobar' like '%foo%') |
+------------------------------------------------+
| 0 |
+------------------------------------------------+
1 row in set (11.54 sec)
mysql> select benchmark(100000000, locate('foo', 'abcfoobar'));
+--------------------------------------------------+
| benchmark(100000000, locate('foo', 'abcfoobar')) |
+--------------------------------------------------+
| 0 |
+--------------------------------------------------+
1 row in set (12.48 sec)
mysql> select ##version;
+------------+
| ##version |
+------------+
| 5.5.27-log |
+------------+
1 row in set (0.01 sec)
Related
mysql> select timestamp('2017-06-21 23:45:01') - timestamp('2017-06-21 23:44:58');
+---------------------------------------------------------------------+
| timestamp('2017-06-21 23:45:01') - timestamp('2017-06-21 23:44:58') |
+---------------------------------------------------------------------+
| 43 |
+---------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> select version();
+------------+
| version() |
+------------+
| 5.7.16-log |
+------------+
1 row in set (0.00 sec)
Obviously, it is not calculated as timestamp. Please advise.
You have to use TIMEDIFF() or TIMESTAMPDIFF()
DEMO
SELECT TIMEDIFF(timestamp('2017-06-21 23:45:00') , timestamp('2017-06-21 23:44:58'));
-- result: 00:00:02.
SELECT TIMESTAMPDIFF(SECOND,'2017-06-21 23:45:00','2017-06-21 23:44:58');
-- result: -2
Simple MAX query:
SELECT MAX(Group) FROM acme
Works fine on a numeric column.
Is it possible to use to this on an alpha-numeric column and ignore anything other than a number?
yes if you cast it before use like this
mysql> SELECT MAX(CAST("123" AS UNSIGNED));
+------------------------------+
| MAX(CAST("123" AS UNSIGNED)) |
+------------------------------+
| 123 |
+------------------------------+
1 row in set (0.00 sec)
mysql> SELECT MAX(CAST("abc" AS UNSIGNED));
+------------------------------+
| MAX(CAST("abc" AS UNSIGNED)) |
+------------------------------+
| 0 |
+------------------------------+
1 row in set, 1 warning (0.00 sec)
mysql> SELECT MAX(CAST("-123" AS SIGNED));
+-----------------------------+
| MAX(CAST("-123" AS SIGNED)) |
+-----------------------------+
| -123 |
+-----------------------------+
1 row in set (0.00 sec)
replace your string column name with "abc" and modify query acording to your requirment
Who can share practical examples of the use of the GET_LOCK function?
Example function:
mysql> SELECT GET_LOCK('b',10);
+------------------+
| GET_LOCK('b',10) |
+------------------+
| 1 |
+------------------+
1 row in set (0.00 sec)
mysql> SELECT IS_FREE_LOCK('b');
+-------------------+
| IS_FREE_LOCK('b') |
+-------------------+
| 0 |
+-------------------+
1 row in set (0.00 sec)
mysql> SELECT RELEASE_LOCK('b');
+-------------------+
| RELEASE_LOCK('b') |
+-------------------+
| 1 |
+-------------------+
1 row in set (0.00 sec)
mysql> SELECT IS_FREE_LOCK('b');
+-------------------+
| IS_FREE_LOCK('b') |
+-------------------+
| 1 |
+-------------------+
1 row in set (0.00 sec)
Thank you.
Resource locking, eg execute only once in some distributed systems.
For example here's tiny app which uses it: https://gist.githubusercontent.com/karnauskas/f6dd0a8608c9a335e17890d3755d5d5a/raw/6bdfa36d93ac1f171ccf0ba5152aa8765c052a96/mysql_lock.go
Implementing distributed locking, as described in this article.
Essentially, if you need to restrict access to some resource X for programs P1, P2, P3, ..., then each program needs to call GET_LOCK("some-agreed-on-string") and only the one which got 1 in response proceeds.
I'm testing the InfiniDB community edition to see if it suits our needing.
I imported in a single table about 10 millions rows (loading of data was surprisingly fast), and I'm trying to do some query on it, but these are the results (with NON cached queries.. if query caching exists in InfiniDB):
Query 1 (very fast):
select * from mytable limit 150000,1000
1000 rows in set (0.04 sec)
Query 2 (immediate):
select count(*) from mytable;
+----------+
| count(*) |
+----------+
| 9429378 |
+----------+
1 row in set (0.00 sec)
Ok it seems to be amazingly fast.. but:
Query 3:
select count(title) from mytable;
.. still going after several minutes
Query 4:
select id from mytable where id like '%ABCD%';
+------------+
| id |
+------------+
| ABCD |
+------------+
1 row in set (11 min 17.30 sec)
I must be doing something wrong, it's not possible that it's performing this way with so simple queries. Any Idea?
That shouldn't be the case, there does appear to be something odd going on, see quick test below.
What is your server configuration: memory/OS/CPU and platform (dedicated, virtual, cloud).
Could I get the schema declaration and method to load the data?
Which version are you using? Version 4 community has significantly more features than prior versions, i.e. core syntax matches enterprise.
Cheers,
Jim T
mysql> insert into mytable select a, a from (select hex(rand() * 100000) a from lineitem limit 10000000) b;
Query OK, 10000000 rows affected (1 min 54.12 sec)
Records: 10000000 Duplicates: 0 Warnings: 0
mysql> desc mytable;
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id | varchar(32) | YES | | NULL | |
| title | varchar(32) | YES | | NULL | |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.01 sec)
mysql> select * from mytable limit 150000,1000;
+-------+-------+
| id | title |
+-------+-------+
| E81 | E81 |
| 746A | 746A |
. . .
| DFC8 | DFC8 |
| 2C56 | 2C56 |
+-------+-------+
1000 rows in set (0.07 sec)
mysql> select count(*) from mytable;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
1 row in set (0.06 sec)
mysql> select count(title) from mytable;
+--------------+
| count(title) |
+--------------+
| 10000000 |
+--------------+
1 row in set (0.09 sec)
mysql> select id from mytable where id like '%ABCD%' limit 1;
+------+
| id |
+------+
| ABCD |
+------+
1 row in set (0.03 sec)
mysql> select 28/4;
+--------+
| 28/4 |
+--------+
| 7.0000 |
+--------+
1 row in set (0.00 sec)
Is there a way I can set something system-wide to be more clever about this, or at least to automatically round every float to 2 places?
That's controlled by the div_precision_increment variable:
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_div_precision_increment
MySQL> select ceiling(28/4);
+---------------+
| ceiling(28/4) |
+---------------+
| 7 |
+---------------+
1 row in set (0.00 sec)
MySQL> select format(28/4,0);
+----------------+
| format(28/4,0) |
+----------------+
| 7 |
+----------------+
1 row in set (0.00 sec)
I GOT IT !!!
set div_precision_increment = 0;
MySQL> select 28/4;
+------+
| 28/4 |
+------+
| 7 |
+------+
1 row in set (0.00 sec)
You could also set it globally:
set global div_precision_increment = 0;
or add this to /etc/my.cnf
div_precision_increment=0
I think your answer, if it exists, lies on this page
I have to be honest, I read through the rules about how precision is applied and don't really understand how you end up with 5 digits of precision by diving 28 by 4.
Good luck!