Здравствуйте!
По хорошему нужно посмотреть на вывод
SHOW CREATE TABLE data
и
SHOW VARIABLES LIKE '%char%'
.
Дальше спекулирую, но могу и угадать

Насколько я понимаю, s_json — это просто строка, но вы зачем-то ее сжимаете через COMPRESS.
Из-за этого теряется метаинформация о кодировке строки, и поэтому LIKE не работает. Если структура
таблицы и соединения при этом содержат правильную метаинформацию, то схема всё равно должна
работать нормально. Я сделал вот такой простой тест:
CREATE TABLE foo (a VARCHAR(10));
INSERT INTO foo VALUES ('привет');
SHOW CREATE TABLE foo;
-- CREATE TABLE `foo` (
-- `a` varchar(10) DEFAULT NULL
-- ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE bar SELECT COMPRESS(a) as a FROM foo;
SHOW CREATE TABLE bar;
-- CREATE TABLE `bar` (
-- `a` varbinary(48) DEFAULT NULL
-- ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
SELECT * FROM bar WHERE UNCOMPRESS(a) LIKE '%иве%';
-- строку нашло
Соответственно, ad-hoc-решение — просто убедиться, что кодировки снаружи расставлены верно.
Менее ad-hoc, но более правильное с моей точки зрения решение — избавиться от UNCOMPRESS
совсем, а строки хранить прямо в виде строк. Так и строки будут храниться без потери информации
о кодировках, и не нужно будет делать дважды UNCOMPRESS для такого вида запросов. Если при
этом есть переживание про размер данных, то лучше воспользоваться встроенным механизмом
сжатия InnoDB (
ALTER TABLE data KEY_BLOCK_SIZE=8
), подозреваю, что он будет даже более
эффективным, т.к. будет сжимать блоки, а не отдельные строки.