I am running into trouble converting a time to utc/gmt.
select from_unixtime(1623167869);
2021-06-08 11:57:49
GMT should return 2021-06-08 14:57:49.
FROM_UNIXTIME
The return value is expressed in the session time zone.
https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_from-unixtime
> SET time_zone = '+00:00';SELECT ##SESSION.time_zone;select from_unixtime(1623167869);
Query OK, 0 rows affected (0.000 sec)
+---------------------+
| ##SESSION.time_zone |
+---------------------+
| +00:00 |
+---------------------+
1 row in set (0.000 sec)
+---------------------------+
| from_unixtime(1623167869) |
+---------------------------+
| 2021-06-08 15:57:49 |
+---------------------------+
1 row in set (0.000 sec)
> SET time_zone = '-02:00';SELECT ##SESSION.time_zone;select from_unixtime(1623167869);
Query OK, 0 rows affected (0.000 sec)
+---------------------+
| ##SESSION.time_zone |
+---------------------+
| -02:00 |
+---------------------+
1 row in set (0.000 sec)
+---------------------------+
| from_unixtime(1623167869) |
+---------------------------+
| 2021-06-08 13:57:49 |
+---------------------------+
1 row in set (0.000 sec)
Related
English is not my native language; please excuse typing errors.
Im using 5.5.38-MariaDB.
Mysql statement：
SELECT CAST(11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
AS char);
I get result is 99999999999999999999999999999999999999999999999999999999999999999,why?
Update:
MariaDB [(none)]> SELECT CAST(199999999999999999999999999999999999999999999999999999999999999999999999999999999 AS char);
+-------------------------------------------------------------------------------------------------+
| CAST(199999999999999999999999999999999999999999999999999999999999999999999999999999999 AS char) |
+-------------------------------------------------------------------------------------------------+
| 199999999999999999999999999999999999999999999999999999999999999999999999999999999 |
+-------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
MariaDB [(none)]> SELECT CAST(1999999999999999999999999999999999999999999999999999999999999999999999999999999999 AS char);
+--------------------------------------------------------------------------------------------------+
| CAST(1999999999999999999999999999999999999999999999999999999999999999999999999999999999 AS char) |
+--------------------------------------------------------------------------------------------------+
| 99999999999999999999999999999999999999999999999999999999999999999 |
+--------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)
MariaDB [(none)]> SHOW WARNINGS;
+---------+------+--------------------------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------------------------+
| Warning | 1916 | Got overflow when converting '' to DECIMAL. Value truncated. |
+---------+------+--------------------------------------------------------------+
1 row in set (0.00 sec)
The 1111... is parsed as a number, specifically as DECIMAL(65, ...). 65 is the max; since the thing is bigger than that, it gave you 65 9's. And it gave you a warning (that was probably ignored):
mysql> SELECT CAST(11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 AS CHAR) AS too_big;
+-------------------------------------------------------------------+
| too_big |
+-------------------------------------------------------------------+
| 99999999999999999999999999999999999999999999999999999999999999999 |
+-------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)
mysql> SHOW WARNINGS;
+---------+------+---------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------+
| Warning | 1292 | Truncated incorrect DECIMAL value: '' |
+---------+------+---------------------------------------+
1 row in set (0.00 sec)
What were you hoping to get?
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
How many GET_LOCKS can be handled by a mysql server - by the whole server. I wasn´t able to find anything about its limitations.
As per MySQL documentation GET_LOCK() you cannot hold more than one lock per connection.
As it says
If you have a lock obtained with GET_LOCK(), it is released when you
execute RELEASE_LOCK(), execute a new GET_LOCK(), or your connection
terminates (either normally or abnormally).
So essentially, it depends on No.Of connection. I would say the equation would
No.of GET_LOCK handled = NO.Of Connections handled
I see there is a bug logged where people suggested to have concurrent lock per connection. See here http://bugs.mysql.com/bug.php?id=1118
mysql> SELECT GET_LOCK('s',10);
+------------------+
| GET_LOCK('s',10) |
+------------------+
| 1 |
+------------------+
1 row in set (0.00 sec)
mysql> SELECT GET_LOCK('t',10);
+------------------+
| GET_LOCK('t',10) |
+------------------+
| 1 |
+------------------+
1 row in set (0.00 sec)
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 IS_FREE_LOCK('t');
+-------------------+
| IS_FREE_LOCK('t') |
+-------------------+
| 1 |
+-------------------+
1 row in set (0.00 sec)
mysql> SELECT IS_FREE_LOCK('s');
+-------------------+
| IS_FREE_LOCK('s') |
+-------------------+
| 1 |
+-------------------+
1 row in set (0.00 sec)
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)
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!