Question

Seems like MySQL Bug;
Request:

        SELECT  *
        FROM table
        WHERE (
        id LIKE          '%тест 199%' 
        OR `user` LIKE     '%тест 199%' 
        OR `user_datetime` LIKE '%тест 199%' 
        OR `user_comments` LIKE '%тест 199%' )
        ORDER BY id desc
        LIMIT 0, 10

[Err] 1271 – Illegal mix of collations for operation ‘like’

And when we use latinic.
Request:

        SELECT  *
        FROM table
        WHERE (
        id LIKE          '%test 199%' 
        OR `user` LIKE     '%test 199%' 
        OR `user_datetime` LIKE '%test 199%' 
        OR `user_comments` LIKE '%test 199%' )
        ORDER BY id desc
        LIMIT 0, 10

Request Success;

How to deal with it?

All of my request are generated automatically, i cant change logic coz function generator has many dependence.

Settings:

SET NAMES utf8
Character set utf8 -- UTF-8 Unicode
Collation utf8_general_ci

UPD for @eggyal

Request: 
SHOW CREATE TABLE `comments`
Response:
CREATE TABLE `comments` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user` varchar(255) NOT NULL DEFAULT '',
  `user_datetime` timestamp NULL DEFAULT NULL,
  `user_comments` varchar(128) DEFAULT NULL,
  UNIQUE KEY `id` (`id`) USING BTREE,
  KEY `user_comments` (`user_comments`),
) ENGINE=InnoDB AUTO_INCREMENT=128456 DEFAULT CHARSET=utf8

MySQL Version 5.5.10

Answer 1

What version of MySQL are you using? As stated in the manual:

As of MySQL 5.5.3, implicit conversion of a numeric or temporal value to string produces a value that has a character set and collation determined by the character_set_connection and collation_connection system variables. (These variables commonly are set with SET NAMES. For information about connection character sets, see Section 10.1.4, “Connection Character Sets and Collations”.)

This change means that such a conversion results in a character (nonbinary) string (a CHAR, VARCHAR, or LONGTEXT value), except when the connection character set is set to binary. In that case, the conversion result is a binary string (a BINARY, VARBINARY, or LONGBLOB value).

Before MySQL 5.5.3, an implicit conversion always produced a binary string, regardless of the connection character set. Such implicit conversions to string typically occur for functions that are passed numeric or temporal values when string values are more usual, and thus could have effects beyond the type of the converted value.

Therefore the implicit conversion of your TIMESTAMP column to a string that occurs when using the LIKE operator will always result in a string of the binary character set if you are using a version of MySQL earlier than 5.5.3 irrespective of SET NAMES (curiously this is also the case on sqlfiddle, which claims to be 5.5.20); since such strings cannot be compared with strings in the utf8 character set, you must explicitly convert your user_datetime column to a UTF-8 string:

SELECT   *
FROM     `comments`
WHERE (
         `id`                                LIKE '%тест 199%' 
     OR  `user`                              LIKE '%тест 199%' 
     OR  CONVERT(`user_datetime` USING utf8) LIKE '%тест 199%' 
     OR  `user_comments`                     LIKE '%тест 199%'
)
ORDER BY `id` DESC
LIMIT    0, 10