Ипатьев

Для того, чтобы взять всё из таблицы, но с уникальным условием, надо сначала подумать.
Над тем, от какого конкретно title мы хотим получить id
Если исходить из того, что может быть несколько записей с одним и тем же title, у них будут разные id.
И по этой причине надо задаться вопросом - какой именно id из этих нескольких мы хотим получить. И зачем.

И после этого либо изменить вопрос, либо структуру базы данных.

Нет разницы, один или 10.
Для простоты индекс можно рассматривать как отсортированный список.
Если список учеников в классном журнале отсортирован по алфавиту, то вы довольно быстро найдёте нужного.
А теперь представьте, что вы по тому же самому списку ищете фамилию, на зная первой буквы. И тут уже без разницы, сколько букв мы не знаем. И одной достаточно, чтобы полностью поломать поиск.

Точно такие же проблемы будут и у базы данных. Вместо отсортированного списка с выходом сразу на нужную букву, придётся тупо искать перебором.

Полнотекстовый индекс также не является чем-то особенным в этом плане. Он устроен по совершенно тупому принципу: грубо говоря, БД берёт текст из колонки, и разбивает его на слова. И строит по этим словам снова точно такой же отсортированный список, с указанием, в каких строках это слово используется. То есть когда мы делаем запрос с match, то mysql находит искомое слово в индексе, и возвращает из него все строки.

И точно так же полнотекстовый индекс не работает, если поставить звёздочку спереди. Мануал так и говорит:

Words match if they begin with the word preceding the * operator

То есть звездочка работает только если поставить её в конце слова.
match against ('класс*') найдёт слово "классный", а '*accный' его уже не найдёт.
То есть БД тебе сразу говорит, что для такого поиска полнотекстовый индекс будет бесполезен.

Вопрос сложный, это издержки разработки под виндоуз.
Весь мир давно уже работает с кодировкой utf-8, а эта допотопная система всё ещё выдаёт свои ошибки в 1251.

Я бы не стал делать никаких специальных телодвижений по перекодированию ошибок виндоус. На боевом сервере эта проблема будет неактуальной, а пару раз при разработке можно и потерпеть.
Как вариант - сделать запись ошибок в лог, и смотреть их каким-нибудь Блокнотом - он покажет нормально.
Ещё как вариант - не использовать опенсервер или чем вы там пользуетесь, а использовать встроенный сервер РНР - он перекодирует выводимые на экран ошибки в utf-8.

Можно удалять по первичному ключу, можно помечать как удалённые. Сам вопрос холиварный, единого ответа на него нет. Исходите из требований своей бизнес-логики.
К "выгоде" этот вопрос отношения не имеет.

Для вашего уровня разницы никакой.

Написано же, простым русским языком: download each 24 hours & cache it
То есть никаких "реализовано через api" тут быть не может. Разумеется, при работе с внешними АПИ полученные данные всегда сохраняются локально, и показываются из кэша. В простейшем случае кэш пишется в файл, но удобнее работать с базой.

"Как сохранять данные полученные с api в базу?" вопрос откровенно дурацкий. Точно так же, как и любые другие.

"I am try" звучит примерно как "я попытайся".

По поводу ошибки. Самое важное, чему должен научиться каждый нуб в питоне (а точнее - в программировании в целом) - это такое понятие, как отладка.
В которой нет ничего сложного. Это всего лишь означает посмотреть глазками на результат своих действий.

В том, чтобы наугад писать какие-то слова от балды, нет ничего зазорного - мы все так делаем. Примерно как с английским - да какая разница, try или trying? Но в отличие от английского, языки программирования позволяют нам проверить, соответствует ли результат ожидаемому.
И в данном случае сообщение об ошибке нам даже подсказывает, куда смотреть: ему явно не нравится значение, которое мы добавляем в БД. И дальше надо сделать две простые вещи:
Первое - спросить себя, сколько значений мы хотим добавить в БД?
И второе - распечатать переменную, которая содержит эти самые значения. Сделать такую банальность, как print(val). И сравнить реальность с ожиданиями.
А дальше совсем просто - полюбовавшись на дело рук своих, начинаем смотреть: каких-таких функций мы навызывали, что у нас получился такой результат. И избавиться от ненужной.

Но это всё мелочь и ерунда по сравнению с важнейшим понятием отладки, с которым мы познакомились сегодня. Поэтому повторим:

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

select * from users where rating < ? order by rating desc limit 10
select * from users where rating > ? order by rating limit 10

Кто ж вас учил так с БД работать?
Во-первых, данные всегда должны всегда передаваться в запрос отдельно.
Во-вторых, код соединения совсем непонятный.
Если используется mysql.connector, то надо как-то так

import mysql.connector
conn = mysql.connector.connect(host='127.0.0.1', database='test', user='user', password='')
cursor = conn.cursor()
sql = "UPDATE `user` SET `participate`=%s WHERE `id` = %s"
cursor.execute(sql, [number, id])
conn.commit()

С каких пор LIKE стала работать с регулярками?

select 9998887766 REGEXP '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'