Данила Румянцев

В MySQL 8.0.2 и выше GROUPS - зарезервированное слово. Если хотите так назвать таблицу или колонку, надо брать название в обратные апострофы - `groups`.

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

Возможно многие и не слышали, но тем не менее существуют т.н. In-memory database (по-русски это, кажется, называется "Резидентная база данных", но я не уверен). Применяются такие системы как правило в высоконагруженных приложениях - в системах провайдеров телекоммуникационных услуг, когда-то читал - что в системах он-лайн биржевой торговли и пр. Там где данных очень много и доступ к ним нужен очень быстро. И главное - владелец таких данных оччччеееень богатенький, что-бы позволить себе приобрести оборудование с объемом оперативной памяти сопоставимым с объемом внешней памяти для "обычных" серверов баз данных. И вот тогда, для таких задач все данные СУБД, включая все индексы и другой служебно-вспомогательной информации, загоняются в оперативную память, обеспечивая и нужную скорость доступа и удобство доступа, которое обычно присуще СУБД.
Главнейшая проблема, которую решают разработчики таких систем - как обеспечить целостности базы данных при внезапной перезагрузке систем. Это влияет на производительность In-memory database, заставляя тратить часть вычислительных ресурсов на синхронизацию данных в ОП и резервных копий на внешней памяти.
Список таких систем можно, кстати, найти даже в Википедии:
https://en.wikipedia.org/wiki/List_of_in-memory_da...

Если же "спуститься" с небес на землю и учесть финансовые возможности "нормального" пользователя, то например, в языке программирования Python есть такой модуль - Pandas. По сути он дает удобство доступа к данным, почти такое-же (а может и еще большее) как SQL, сохраняя таблицы в ОП. А скорость обработки - сопоставимую с реализацией на "голых" массивах, а для сложных поисковых запросов - и еще большую. Естественно, что объем таблиц (DataFrame в терминологии Pandas) не может быть слишком большим. И не смотря на то, что есть прямой шлюз для перехода от DataFrame к SQL-структурам СУБД и обратно, скорость работы "в памяти" на много выше, чем скорость работы с теми-же данными, выгруженными в БД. Поэтом программист может комбинировать работу DataFrame для скорости обработки и СУБД для долговременно энергонезависимого хранения, найдя приемлемый для своего приложения компромисс.

Вопрос не глупый а вполне себе хороший.

Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
1) Пока памяти хватает (массив) - используй смело память
2) Диск - больше и дешевле памяти
3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
4) Разные диски имеют скорость на порядки разную.
5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
Ее очень любят обсуждать админы баз данных.
6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
7) Диск - переживает выключение питания.
8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
SQLite например.
10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
для журналирования событий.

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.

Используйте метод строк .splitlines() либо укажите для метода .split() параметр разделитель ”\n”

Почему-то как я не стараюсь всё записывается только в sportsmens[i].full_name,

Поскольку ты используешь fscanf, а поля в твоём файле разделены пробелами, формат fscanf должен включать в себя пробелы чтобы избавиться от разделителей. Кроме того, имеет смысл проверить, что setlocale возвращает не-NULL, иначе он не повлияет на десятичный разделитель (и %f не сможет прочитать число с плавающей точкой записанное как 12,12).

Попробуй использовать Pool.map().
Пример его использования буквально в самом начале официальной документации.

Никак, ограничение гугла. Получаете 500 сообщений, достаете из ответа токен следующей страницы, вызываете этот метод опять, добавив параметр pageToken со значением, которое получили.

как-то так вроде

messages = []
next_page_token = None

for _ in range(3):
    if next_page_token:
        msgs = service.users().messages().list(userId='me',maxResults=500, pageToken=next_page_token).execute()
    else:
        msgs = service.users().messages().list(userId='me',maxResults=500).execute()

    messages.extend(msgs)
    next_page_token = msgs['nextPageToken']

Можно попробовать так:

pseudo_input = driver.find_element_by_css_selector(".btn") # ну или что там у тебя за элемент
( selenium.webdriver.common.action_chains.ActionChains(driver)
    .move_to_element(pseudo_input)
    .click(pseudo_input)
    .send_keys_to_element(pseudo_input, *keys_to_send)
    .perform()
)