Люди, помогите!

Значение в поле s.field_see_value примерно такого содержания - 296;689;211;740;135;140;744;64;311;416
Мне нужно проверить наличие любого из этих значений (296 или 211 или 64 или т.д.) с другим списком (см. внутр. селект - SELECT DISTINCT field_see_value....)
Есть ли возможность разбить значение поля s.field_see_value по спецсимволу ";", чтоб найти любое значение этого поля со списком, который выбирается?

Или быть может имеется другой способ написания выборки? 

Если имеется строковый список (list='296;689;211;740;135;140;744;64;311;416'), и надо проверить наличие в нём определённого значения (value='296'), то можно это сделать несколькими способами.

Самый простой для понимания:

я так понял это подойдет к поиску одного значения (value='296') в списке (list='296;689;211;740;135;140;744;64;311;416')
но,дело в том что у меня нужно проверить есть ли любое значение (value='296;64;555') из поля s.field_see_value в списке  (list='296,689,211,740,135,140,744,64,311,416') (формируется по внутр.селекту) , т.е. если либо 296 либо 64 либо 555 из значения поля s.field_see_value находится в списке list

MySQL - реляционная БД.
Ваш подход ничего общего с реляционным не имеет. Похоже, опыт процедурного программирования есть, а SQL-ного - нет, именно это и мешает.
Переделывайте мышление. А потом - логику приложения и структуры БД.

1. решение простое, медленное и громоздкое: при формировании запроса разбить маленький список для поиска на отдельные условия:

становится 
медленное решение по двум причинам: строковые операции на значении нефиксированной длины и невозможность использовать индексы.
2. решение, о котором говорил Akina: изменить структуру БД, чтоб у тебя было один-ко-многим и эти самые value хранились не в виде одного значения с сериализированным списком, а в отдельной таблице на каждое число отводилась отдельная запись.
впрочем, список значений для поиска все равно придется разбивать при формировании запроса:


советую применять решение 1 только в том случае, если пример учебный и сдать надо быстро, а показывать "правильность" опасно — ну, вопросами там ненужными грузить начнут   
а так — преимущества второго варианта как в скорости, так и в гибкости. 

То что не правильная структура БД - согласен. К сожалению показанный пример от skyboy не совсем подходит, т.к. значения table2.value = 296 OR table2.value = 64 OR table2.value = 555, которые мы будем искать в списке, могут быть разными и их кол-во также ....
Придется вносить изменения в структуру БД....

так я ж писал. ты запрос как формируешь?